The following bug has been logged online:
Bug reference: 1147
Logged by: Harald Fricke
Email address: hfricke@hdz-nrw.de
PostgreSQL version: 7.4
Operating system: Solaris 8
Description: Getting rid of LD_LIBRARY_PATH
Details:
I've got a problem with the build process on Solaris 8 with gcc 3.3.2,
libraries installed in /usr/local.
./configure LDFLAGS="-R /usr/local/lib" --with-tcl
--prefix=/soft/pgsql-7.4.2 --with-libs=/usr/local/lib
Note the LDFLAGS telling the linker to record /usr/local/lib as library
search path in the executables.
Building works fine, but pgsql and the other executables fail with
"libgcc_s.so.1: not found" unless I set LD_LIBRARY_PATH to /usr/local/lib.
ldd -ls psql shows libpq.so.3 to be the culprit:
find object=libgcc_s.so.1; required by
search path=/soft/pgsql-7.4.2/lib (RPATH from file ../lib/libpq.so.3)
trying path=/soft/pgsql-7.4.2/lib/libgcc_s.so.1
search path=/usr/lib (default)
trying path=/usr/lib/libgcc_s.so.1
libgcc_s.so.1 => (file not found)
It looks as if the -R linker directive is not passed to commands building
the shared libraries.
Using LD_LIBRARY_PATH is not a good idea for production software (see
http://www.visi.com/~barr/ldpath.html) and I would like to get rid of it.
Proposed fix: Ideally, all invocations of the linker should set the run-time
search path to all paths from which libraries are pulled. I understand this
will be difficult for the gcc run-time libraries because there is no API to
ask gcc for the location.
An easier way would be to append the value of LDFLAGS to the linker commands
building the shared libraries, not only to those building the executables.
Maybe it would be a good idea to pass a -R arguments to the linker for each
--with-libs configure switch. After all, if the user wants to use a library
directory, it will probably needed at run-time too.
I am afraid that I cannot fix the problem myself. The build process is quite
complex and I do not speak autoconf or GNU make.
Hope I made myself clear...
Regards,
Harald Fricke
