🚀 go-pugleaf

Milan Schulte <Milan.Schulte@OFFIS.de> wrote in message news:<9ov1ph$asn@news.Informatik.Uni-Oldenburg.DE>...
> Paul Floyd wrote:
> 
> > On Wed, 26 Sep 2001 00:15:40 -0400, David Michaels
> >    <michaedi@email.uc.edu> wrote:

> >>I was thinking that you set the LD_LIBRARY_PATH to find the file
> >>libstdc++, because thats where iostream is.

> > There's much debate about LD_LIBRARY_PATH. My feeling is that you're better
> > off using the -R option, or else LD_RUN_PATH. These will compile the lib
> > paths into your binary, rather than relying on LD_LIBRARY_PATH.

> This means coding the _absolute_ path in the binary. In some cases (e.g. binary
> gets shipped to another user/system, who installs it somewhere else) this is not
> desired. Evtl. libstdc++ should be linked statically in such cases.

So what is your point? If you don't use -R/LD_RUN_PATH, then an
application certainly won't run if it is dependent on libraries stored
in non-standard directories. You will still be able to use the
LD_LIBRARY_PATH to override the hard coded runtime linker paths.

If your installation routine consists of "copy the binary somewhere in
your path", then LD_LIBRARY_PATH is probably just right.

The real problem comes when you have a great big long LD_LIBRARY_PATH,
which can then easily break applications compiled with -R that would
work perfectly *without* LD_LIBRARY_PATH.

A bientot
Paul