Skip site navigation (1) Skip section navigation (2)

Re: BUG #4219: fseeko test failure in configure script

From: Nathan Reed <nreed(at)uci(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgreSQL(dot)org, nreed(at)uci(dot)edu
Subject: Re: BUG #4219: fseeko test failure in configure script
Date: 2008-06-05 17:22:44
Message-ID: 200806051722.m55HMk2J001150@smtp1.es.uci.edu (view raw or flat)
Thread:
Lists: pgsql-bugs
Tom,
    LD_LIBRARY_PATH is the correct env var to use.  However, you are 
correct that this hamstrings the generated executable - requiring 
that the LD_LIBRARY_PATH include all of the shared object libraries 
in the rc scripts themselves.

    Regarding the possibility of a bug, I had indicated that I 
performed the ld command from the command in the postgres build area 
and did not have an error returned.  Here is the listing of the ssl 
lib area (done with pkgadd):

# cd /usr/local/ssl/lib
# ls -l
total 9004
-rwxrwx--x   1 root  root        1540 Jun  5 08:49 a.out
drwxr-xr-x   2 bin   bin          512 Jun  3 11:15 engines
-rw-r--r--   1 bin   bin      2290290 May 30 02:54 libcrypto.a
lrwxrwxrwx   1 root  root    18 Jun  3 11:15 libcrypto.so -> libcrypto.so.0.9.8
-r-xr-xr-x   1 bin   bin      1559648 May 30 02:54 libcrypto.so.0.9.8
-rw-r--r--   1 bin   bin       404896 May 30 02:54 libssl.a
lrwxrwxrwx   1 root  root          15 Jun  3 11:15 libssl.so -> libssl.so.0.9.8
-r-xr-xr-x   1 bin   bin       302776 May 30 02:54 libssl.so.0.9.8
drwxr-xr-x   2 bin   bin          512 Jun  3 11:15 pkgconfig

The links are there from libssl to the specific shared object lib and 
all of the packages I added were built using the gcc compiler.


Nathan K. Reed
Programmer/Analyst
Supervisor of Records group
University of California, Irvine
Office of Admissions and Relations with Schools
(949) 824-9631


At 09:55 AM 6/5/2008, Tom Lane wrote:
>[ please keep the mailing list cc'd ]
>
>Nathan Reed <nreed(at)uci(dot)edu> writes:
> > Here is the dump of the config.log file in the pertinent area:
>
> > configure:19839: checking test program
> > configure:19854: gcc -o conftest -O2 -Wall -Wmissing-prototypes
> > -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels
> > -fno-strict-aliasing
> > -fwrapv  -I/usr/local/include/libxml2  -I/usr/local/ssl/include
> > -I/usr/local/BerkeleyDB.4.2/include  -L/usr/local/lib  -L/usr/lib
> > -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib -L/usr/ccs/lib
> > -L/usr/ucblib conftest.c -lxslt -lxml2 -lssl -lcrypto -lz -lreadline
> > -ltermcap -lrt -lsocket -lm  >&5
> > configure:19857: $? = 0
> > configure:19859: ./conftest
> > ld.so.1: conftest: fatal: libssl.so.0.9.8: open failed: No such file
> > or directory
> > ./configure: line 19860:   641 Killed                  ./conftest$ac_exeext
> > configure:19862: $? = 137
> > configure: program exited with status 137
>
>Personally I would argue that this is a bug in your operating system ;-)
>
>What is happening is that the generated object file just references
>"libssl.so.0.9.8" without any memory of where it had been found at
>link time, and if the dynamic linker doesn't search all the same
>directories as you had -L switches for, you lose.
>
>One workaround is to set LD_LIBRARY_PATH (or perhaps LD_RUN_PATH, but
>never having worked on Solaris I'm not too sure which).  This isn't
>very desirable because you'd have to do the same whenever invoking
>Postgres programs.  It'd be better to alter the dynamic linker's
>configuration to make sure it searches all of your nonstandard library
>locations, or if you can't do that move all your libraries into the
>standard directories.
>
>                         regards, tom lane




In response to

Responses

pgsql-bugs by date

Next:From: Simon RiggsDate: 2008-06-05 17:28:26
Subject: Re: BUG #3110: Online Backup introduces Duplicate OIDs
Previous:From: Tom LaneDate: 2008-06-05 16:55:54
Subject: Re: BUG #4219: fseeko test failure in configure script

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group