SUMMARY: The evil LD_LIBRARY_PATH

Okay guys,

first of all I must admit that I'm a little bit dumb. I failed to mention 
the OS I'm using. As many of you guessed correctly, my question was about 
Solaris 2.8. I even led some of you to believe the question was about Linux. 
Next time I'll try to be more precise.

The solution is:

	crle -l /usr/lib:/usr/local/lib
	crle -u

Since we're talking about an application that was compiled with GCC 2.95.3
I won't look into 64-bit stuff at this point.

The most speedy reply (took a single minute) was:

Da ich vom 21.05. bis 03.06.02 Urlaub habe, kann ich Ihre
E-Mail erst am 04.06.02 lesen.
Diese Mail wird nicht weitergeleitet.

Just kidding, this was an Out-Of-The-Office notification from Germany. ;-)

One comprehensive list from Dan Astoorian:

*snip*
In order from most- to least-preferred:

1) Compile your applications correctly.  The application should be told
at compile time, via the -R flag (or, if using gcc, "-Xlinker -rpath=...")
where to search for its shared libraries; it shouldn't have to rely on
an environment variable.

2) If you're using Solaris 8 or later (you didn't say in your message),
consult the documentation for the "crle" command.

3) In a pinch, you could link or copy the libraries in /usr/local/lib
to a directory in the standard library path, such as /usr/lib .

You're very correct that LD_LIBRARY_PATH should be avoided; I'll spare
you the laundry list of reasons.
*snip*

The laundry list is here:

http://www.visi.com/~barr/ldpath.html

Another useful link, the Sun compile FAQ:

http://inscoe.org/compilesun


A few suggestions pointed to LD_RUN_PATH e.g.:

*snip*
Rebuild 'rsync'.

This time, set 'LD_RUN_PATH' to '/usr/local/lib' prior to compiling. (Or modify
the Makefile to add a '-R/usr/local/lib' right after the '-L/usr/local/lib')

Either of the two methods above will encoded /usr/local/lib as an additional
library search path into the executable.

Note: This is a good practice for all executable you build, that depend upon
non-/usr/lib libraries.

Note: Sun has been doing this for /usr/openwin since Solaris 2.5, and CDE since
Solaris 2.6.
*snip*

Thanks to Peter Evans who got me started with a real-life crle command 
line copied and pasted from his japanese (aargh) terminal.

Thanks everyone,

-martin


* Martin Schmitt wrote/schrieb:

> Hi folks!
> 
> I'm suffering from LD_LIBRARY_PATH-itis. Fortunately it's only one
> directory that's contained therein: /usr/local/lib
> 
> I have added /usr/local/lib to LD_LIBRARY_PATH in /etc/profile, so on every
> interactive session the environment is set and everything works fine.
> 
> Unfortunately if it's a non-interactive session, things start to go awry.
> In my case, rsync is causing the trouble:
> 
> [martin@linuxbox martin]$ rsync --rsh="ssh" \
>                                 --rsync-path=/usr/local/bin/rsync \
>                                 solarisbox:/etc/hosts /dev/null
> 
> ld.so.1: /usr/local/bin/rsync: fatal: libpopt.so.0: open failed: No such
> file or directory
> Read from remote host solarisbox: Connection reset by peer
> rsync: connection unexpectedly closed (0 bytes read so far)
> rsync error: error in rsync protocol data stream (code 12) at io.c(150)
> 
> The reason is extremely clear: LD_LIBRARY_PATH is missing. One solution to
> get out of this would be to write some kind of wrapper script for rsync and
> put it into the --rsync-path option. Another one might be to create a
> statically linked rsync. I don't particularly like either option.
> 
> I recall reading (and not quite understanding) a text about why 
> LD_LIBRARY_PATH is bad and how it can be replaced. But as I said, I wasn't 
> able to grok it, and I can't recall where I saw it anyway. On my Linux boxes 
> I know /etc/ld.so.conf as the central place for adding library paths, so I'm 
> traditionally not too comfortable about LD_LIBRARY_PATH.  
> 
> How can I - in a nutshell - replace LD_LIBRARY_PATH by a constant and 
> system-wide setting?
> 
> Thanks in advance,
> 
> -martin
> 
> -- 
> There are 3 sides to every argument: Mine, yours, and the right side.
> _______________________________________________
> sunmanagers mailing list
> sunmanagers@sunmanagers.org
> http://www.sunmanagers.org/mailman/listinfo/sunmanagers

-- 
a man a plan a canal panama
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers