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
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
