On Wed, 30 Jul 2003, Martin Hepworth wrote:

> what's the LD_LIBRARY_PATH set to? does it include the location of
> libgcc_s.so?

I don't use LD_LIBRARY_PATH and have no need to do so. That's what the
purpose of the -R linker flag is - to hard-code the library search path
that the executable file will use at *runtime*. The -L flag tells the
linker where to search at *compile* time, but this doesn't replace
whatever is supplied with the -R flag.

It's a good question that you raised though since with Solaris and most
other Unixes, using LD_LIBRARY_PATH is a serious enough security issue
that it's used very little anymore, and many people prefer to use the
-L/-R combination in the LDFLAGS setting.

My default -R flag setting is /usr/sfw/lib:/usr/openwin/lib:/usr/local/lib
so at run-time, the program will check through these three directories for
each shared library it needs to find. I have /usr/local/lib last since Sun
now supplies a lot of pre-compiled 3rd-party software packages configured
to install into the /usr/sfw path. I don't have any Sun-supplied GCC
installations, and the default paths for gcc files are all under
/usr/local, so the genversion binary should be detecting libgcc_s in
/usr/local/lib and using it.

Either something is wrong with libgcc_s and the run-time wrapper rejects
the shared library as being invalid, or something is wrong with the way
the run-time wrapper is built when genversion is compiled that means it
doesn't search /usr/local/lib to see if it can find libgcc_s there.

At least they're my two current theories.

Craig.

-- 
     Email by Craig Dewick (tm). Home page at "lios.apana.org.au/~cdewick".
        "cdewick AT spam.lios.apana.org DOT au" or "cdewick AT spam.sunshack 
DOT org".
 Explore and enjoy my public-domain Sun Microsystems technical data archive at
         "www.sunshack.org", "www.sunshack.net" or "www.sunshack.info".