From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28299 invoked by alias); 12 May 2004 19:36:46 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 28287 invoked from network); 12 May 2004 19:36:44 -0000 Received: from unknown (HELO masquerade.micron.com) (137.201.242.130) by sourceware.org with SMTP; 12 May 2004 19:36:44 -0000 Received: from mail-srv2.micron.com (localhost [127.0.0.1]) by masquerade.micron.com (8.12.9/8.12.2) with ESMTP id i4CJaoPY011634 for ; Wed, 12 May 2004 13:36:50 -0600 (MDT) Received: from ntxboimbx07.micron.com (ntxboimbx07.micron.com [137.201.80.94]) by mail-srv2.micron.com (8.12.9/8.12.2) with ESMTP id i4CJanMf011625; Wed, 12 May 2004 13:36:49 -0600 (MDT) From: lrtaylor@micron.com content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: libgcc_s.so.1: open failed: No such file or directory Date: Wed, 12 May 2004 19:36:00 -0000 Message-ID: <363801FFD7B74240A329CEC3F7FE4CC40215DADD@ntxboimbx07.micron.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: To: Cc: X-Scanned-By: MIMEDefang 2.37 X-SW-Source: 2004-05/txt/msg00151.txt.bz2 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]=20 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. > * [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=3D`gcc -m64 -print-file-name=3Dlibgcc_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 --=20 Sam Steingold (http://www.podval.org/~sds) running w2k The only time you have too much fuel is when you're on fire.