libgcc_s.so.1: open failed: No such file or directory

[lrtaylor@micron.com]

OK.  I think I may see your problem.  It looks like lisp.run does not
directly depend on libgcc_s.so.1, but, rather, one of the libraries that
you're linking to depends on it, giving lisp.run an implicit dependency
on it.  The problem is that the linker only uses the embedded runpath
(RPATH) to load libraries that it directly depends on (the ones listed
on the NEEDED lines).  When it attempts to load one of those, it will
check for libraries that they depend on and if there is an embedded
RPATH in them, it will use that.  Otherwise, it will use
LD_LIBRARY_PATH, etc.  But it will NOT use the path embedded in
lisp.run.  Does that make sense.

For example, say we have a dependency relationship like this:

A -> B -> C

That is, where A depends directly on B, and B depends directly on C, but
A has not direct dependency on C.  If B and C are in the same directory
(say, /foo/lib), and /foo/lib is embedded in A, but not in B, then when
the linker looks for B, it will look in /foo/lib for B, and then see
that B needs C.  However, since /foo/lib is not embedded in B, it will
NOT look in /foo/lib for C, unless it's also in LD_LIBRARY_PATH or
something like that.  It won't use the /foo/lib embedded in A to find C
for B.

So, what does that mean?  If you don't want to set LD_LIBRARY_PATH, then
you need to find the library that depends on libgcc_s.so.1 (I suspect
libreadline.so.4) and rebuild it with the path to libgcc_s.so.1 embedded
in it.

Cheers,
Lyle

-----Original Message-----
From: Sam Steingold [mailto:sds@gnu.org] 
Sent: Wednesday, May 12, 2004 12:43 PM
To: lrtaylor
Subject: Re: libgcc_s.so.1: open failed: No such file or directory

The following message is a courtesy copy of an article
that has been posted to gmane.comp.gcc.help as well.

> *  <yegnlybe@zvpeba.pbz> [2004-05-12 11:22:00 -0600]:
>
> What do you get if you run this?
> 	elfdump -d lisp.run


Dynamic Section:  .dynamic
     index  tag               value
       [0]  NEEDED           0x6079            libreadline.so.4
       [1]  NEEDED           0x608a            libcurses.so.1
       [2]  NEEDED           0x6099            libdl.so.1
       [3]  NEEDED           0x60a4            libnsl.so.1
       [4]  NEEDED           0x60b0            libsocket.so.1
       [5]  NEEDED           0x60bf            libiconv.so.2
       [6]  NEEDED           0x60cd            libc.so.1
       [7]  INIT             0x10011d614
       [8]  FINI             0x10011d630
       [9]  RUNPATH          0x60d7
/home/sds/src/m64/lib:/atech/gcc-3.2.2/lib/sparcv9
      [10]  RPATH            0x60d7
/home/sds/src/m64/lib:/atech/gcc-3.2.2/lib/sparcv9
      [11]  HASH             0x100000178
      [12]  STRTAB           0x10000d408
      [13]  STRSZ            0x610a
      [14]  SYMTAB           0x100003640
      [15]  SYMENT           0x18
      [16]  CHECKSUM         0xce7d
      [17]  VERNEED          0x100013518
      [18]  VERNEEDNUM       0x4
      [19]  PLTRELSZ         0xde0
      [20]  PLTREL           0x7
      [21]  JMPREL           0x100013710
      [22]  RELA             0x1000135a8
      [23]  RELASZ           0xf48
      [24]  RELAENT          0x18
      [25]  REGISTER         0x37
      [26]  DEBUG            0
      [27]  FEATURE_1        0x1               [ PARINIT ]
      [28]  FLAGS            0                 0
      [29]  FLAGS_1          0                 0
      [30]  PLTGOT           0x1002b6f00

> You should see a line for RPATH.  If so, does it contain the right
> directory?

yes.

> Have you verified that the directory given by your gcc command given
> below is really correct?

$ d=`gcc -m64 -print-file-name=libgcc_s.so.1`
$ echo $d
/atech/gcc-3.2.2/lib/gcc-lib/sparc-sun-solaris2.7/3.2.2/../../../sparcv9
/libgcc_s.so.1
$ cd `dirname $d`
$ pwd
/atech/gcc-3.2.2/lib/sparcv9
$

> That is, that the library is indeed in that directory?

yes:
/atech/gcc-3.2.2/lib/sparcv9/libgcc_s.so.1:     ELF 64-bit MSB dynamic
lib SPARCV9 Version 1, dynamically linked, not stripped

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
The only time you have too much fuel is when you're on fire.