Обсуждение: BUG #1147: Getting rid of LD_LIBRARY_PATH

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

"PostgreSQL Bugs List" <pgsql-bugs@postgresql.org> writes:
> ./configure LDFLAGS="-R /usr/local/lib" --with-tcl

Actually, the way this is intended to be handled is to set "rpath"
in the platform-specific Makefile.  It looks to me like
src/makefiles/Makefile.solaris does so; can you look into it and
see why that doesn't work for you?

> 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.

AFAICS we do that too.  So I'm still confused why you have a problem.

            regards, tom lane

Am Donnerstag, 6. Mai 2004 18:30 schrieb Tom Lane:
> "PostgreSQL Bugs List" <pgsql-bugs@postgresql.org> writes:
> > ./configure LDFLAGS="-R /usr/local/lib" --with-tcl

> > 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.
>
> AFAICS we do that too.  So I'm still confused why you have a problem.

We only take the -L flags from LDFLAGS for the shared library link.  This is
probably a result of paranoia.  Can you think of a flag that is reasonable
for a user to set in LDFLAGS by hand that should not end up in the shared
library link?  Useful LDFLAGS I can think of are -L, -l, -R (or equivalent),
debugging, optimization, profiling, and maybe some 32/64 bit selection, and
all of these can be passed to the shared library link.  I'm not sure,
however, about the assignments in Makefile.hpux.

Peter Eisentraut <peter_e@gmx.net> writes:
> We only take the -L flags from LDFLAGS for the shared library link.  This is
> probably a result of paranoia.  Can you think of a flag that is reasonable
> for a user to set in LDFLAGS by hand that should not end up in the shared
> library link?  Useful LDFLAGS I can think of are -L, -l, -R (or equivalent),
> debugging, optimization, profiling, and maybe some 32/64 bit selection, and
> all of these can be passed to the shared library link.  I'm not sure,
> however, about the assignments in Makefile.hpux.

I think the HPUX flags would be ok; leastwise, if they are not, I'll
soon find out ;-).

If you think this would be a good change, go ahead and make it.  I'd
suggest however that there needs to be a way for the Makefile.port files
to supply loader flags that are used only for executables.  It doesn't
have to be called LDFLAGS though...

            regards, tom lane