Re: reference to libgcc_s.so.1 without a corresponding run path

[Alessandro Vesely]

Bruce Korb wrote:
> Bob Friesenhahn wrote:
> > On Wed, 1 Oct 2008, Bruce Korb wrote:
> > > > > /home/usr/bkorb/tools/ag/autogen-5.9.6pre15/_b/agen5/.libs/autogen: 
> > > > > fatal: libgcc_s.so.1: open failed: No such file or directory
> >
> > Note that this problem is not libtool's fault.  For very good reasons 
> > (e.g. many applications stop working if some old GCC is uninstalled), 
> > the path to this shared library should not be automatically hard 
> > coded.  This library is part of GCC and needs to be incorporated into 
> > the system's run-time library search path somehow such as via 'crle', 
> > LD_LIBRARY_PATH, or symbolic link.
>
> Hi Bob,
>
> I guess it is a sysadmin's fault.  Non-libtoolized stuff seems to build,
> and libtoolized stuff with ``--disable-shared'' specified works okay,
> so building a case that IT needs to fix something isn't going to be
> easy.

IME, running crle (configure runtime linking environment) is required 
to configure /usr/local/lib for running 32bit executables. One may 
want to also create /usr/local/lib/64. IIRC, gcc 3 does neither.

Actually, there are some packages that allow building both 32 and 64 
bits libraries, in case you need to build a 64 bit utility. Thus, I 
agree that configuration should have been carried out. See, e.g., 
http://bwachter.lart.info/solaris/solfaq.html

>  Using LD_LIBRARY_PATH caused other little glitches.  (I forget
> what, exactly.  My head got whacked, I stopped doing it and years have
> passed now....)

(Perhaps that was that it's never clear if it is a runtime or compile 
time directive)

hth