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.