On Fri, Apr 21, 2006 at 09:41:54AM -0400, stan wrote: > I'm starting to upgrade my clients. The HP-UX boxes (10.20) went flawlessly. > > But I'm having a few issues with my first Solaris 8 machine. Now in the > interest of full disclosure, these machines are "supported" by a 3rd party > OEM, and the machine I use for a build machine was recently "rebuilt" by > them to address a kernel memory leak issue, so odds are good what I'm > seeing is a result of their meddling, but I could use some help figuring > this out. > [snip] > > My first amcheck failed. I tried to run amandad by hand, and found that the > dynamic linker was failing to find libgcc_s.so.1. I looked in .cshrc and > .profile, and found that they had broken LD_LIBRARY_PATH. I fixed this, > restarted inetd, and was able to run an amcheck. So far so good.
LD_LIBRARY_PATH is at best a kludge. Needing to use it is always a sign that something's broken. (Having a 537 character PATH generally is, as well.) > But, the next backups from this machine failed, and when I look in the > debug file, I find this: > > ld.so.1: /opt/amanda/libexec/noop: fatal: libgcc_s.so.1: open failed: No > such file or directory > > I'm a bit confused by what sets up the search path for shared libraries > under Solaris 8, when they are invoked as services like Amanda does. Is > there a way to give the binaries a hard coded search path? Yes, pass the -R/path/to/library flag to the linker at build time. For Solaris systems, every -L given to the linker should have a corresponding -R. libgcc_s.so.1 is a bit of a special case, since gcc is implicitly linking that one in when needed. Figure out where it lives and pass the appropriate -R option via LDFLAGS when building.
