gdb: dyld: Library not loaded @rpath/libCore.so

[alkulakov@…]

I used gdb normally until this week. Now running gdb I see:

    (gdb) r
    Starting program: /Volumes/MyProg 
    dyld: Library not loaded: @rpath/libCore.so
      Referenced from: /Volumes/MyProg
      Reason: image not found
    (gdb) 

How to fix it?

I have:

• OSX 10.9
• MacPorts 2.2.1
• GNU gdb (GDB) 7.6 installed with MacPorts

[ryandesign (Ryan Carsten Schmidt)]

Does this happen when running any other program? Or just "MyProg"?

The gdb port hasn't been changed in over half a year. It doesn't sound like a MacPorts problem to me.

[alkulakov@…]

Replying to ryandesign@…:

Does this happen when running any other program? Or just "MyProg"?

The gdb port hasn't been changed in over half a year. It doesn't sound like a MacPorts problem to me.

I tried 2 different programs.

I believe this is MacPorts + OSX combination... until Maveriks I had no troubles with gdb... But I have no I idea where to look. What is @path, which image?

[ryandesign (Ryan Carsten Schmidt)]

Here's one article that explains @rpath: ​http://www.dribin.org/dave/blog/archives/2009/11/15/rpath/

[moo@…]

I have this problem as well. Here are some specifics:

I'm working on a project where we have to build our own versions of common things like openssl, as well as our own libraries. To run these programs from the command line, it's necessary to set the DYLD_LIBRARY_PATH, but once that is done everything works fine. Furthermore, gdb 6.3.50 is able to load and run the programs just fine, as long as DYLD_LIBRARY_PATH is set when gdb is invoked.

On the other hand, gdb 7.6 as installed by macports doesn't seem to honor DYLD_LIBRARY_PATH, or it has some problem that has the same effect. Below you'll find some info about my environment, followed by output from gcc 6.3.50, followed by the error from gdb 7.6.

Please contact me if you need further details-- I'm happy to assist any way that I can. :-)

oberon:bin rselph$ echo $DYLD_LIBRARY_PATH
/rv/build/dev/rselph/messaging/trunk/hydra/macosx_x86_64/bin/lib

oberon:bin rselph$ ls $DYLD_LIBRARY_PATH
eftl.js                          libtib.1.dylib@                  libtibftlrs.2.4.1.0.dylib*       libtibmcast.dylib@
json_simple-1.1.jar              libtib.dylib@                    libtibftlrs.2.dylib@             libtibrv64.dylib
junit-3.8.2.jar                  libtibftlap.1.1.0.0.dylib*       libtibftlrs.dylib@               libtibutil.1.4.1.0.dylib*
libcrypto.1.0.0.dylib            libtibftlap.1.dylib@             libtibgroup.1.4.1.0.dylib*       libtibutil.1.dylib@
libcrypto.dylib@                 libtibftlap.dylib@               libtibgroup.1.dylib@             libtibutil.dylib@
libcurl.4.dylib                  libtibftlgroupjni.1.4.1.0.dylib* libtibgroup.dylib@               simplejson/
libcurl.dylib@                   libtibftlgroupjni.1.dylib@       libtibhelper.1.4.1.0.dylib*      tibeftl.jar
libssl.1.0.0.dylib               libtibftlgroupjni.dylib@         libtibhelper.1.dylib@            tibftl.jar
libssl.dylib@                    libtibftljni.2.4.1.0.dylib*      libtibhelper.dylib@              tibftl_test.jar
libtestutil.dylib*               libtibftljni.2.dylib@            libtibmcast.2.4.1.0.dylib*       tibftlgroup.jar
libtib.1.4.1.0.dylib*            libtibftljni.dylib@              libtibmcast.2.dylib@

oberon:bin rselph$ otool -L ./curltest 
./curltest:
	/rv/scratch/curl/curl-7.34.0-install/lib/libcurl.4.dylib (compatibility version 8.0.0, current version 8.0.0)
	/usr/local/ssl/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/local/ssl/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)

oberon:bin rselph$ ./curltest 
cURL version: 7.34.0
host: x86_64-apple-darwin13.0.0
SSL version: OpenSSL/1.0.1f
protocol: file
protocol: gopher
[... further output omitted]


oberon:bin rselph$ /usr/bin/gdb ./curltest
GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (Wed Feb  6 22:51:23 UTC 2013)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ..... done

(gdb) r
Starting program: /rv/build/dev/rselph/messaging/trunk/hydra/macosx_x86_64/bin/bin/curltest 
Reading symbols for shared libraries ++++.......................... done
cURL version: 7.34.0
host: x86_64-apple-darwin13.0.0
SSL version: OpenSSL/1.0.1f
protocol: file
protocol: gopher
[... further output omitted]


oberon:bin rselph$ /opt/local/bin/ggdb ./curltest 
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin13.0.0".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /rv/build/dev/rselph/messaging/trunk/hydra/macosx_x86_64/bin/bin/curltest...(no debugging symbols found)...done.
(gdb) r
Starting program: /rv/build/dev/rselph/messaging/trunk/hydra/macosx_x86_64/bin/bin/curltest 
dyld: Library not loaded: /rv/scratch/curl/curl-7.34.0-install/lib/libcurl.4.dylib
  Referenced from: /rv/build/dev/rselph/messaging/trunk/hydra/macosx_x86_64/bin/bin/curltest
  Reason: Incompatible library version: curltest requires version 8.0.0 or later, but libcurl.4.dylib provides version 7.0.0

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007fff5fc0109d in ?? ()
(gdb) 

[moo@…]

Cc Me!

[neverpanic (Clemens Lang)]

Replying to moo@…:

I'm working on a project where we have to build our own versions of common things like openssl, as well as our own libraries. To run these programs from the command line, it's necessary to set the DYLD_LIBRARY_PATH, but once that is done everything works fine.

It is not necessary to set DYLD_LIBRARY_PATH in this case. If you ensure the binary you are running contains the correct absolute path of the library it will work just fine without DYLD_LIBRARY_PATH set. To do this, use install_name_tool -change on the binary, or ensure the libraries you link against contain the correct absolute path to themselves as the ID load command (the first line printed in otool -L output) before linking the binary. You can change the ID using install_name_tool -id or using the -install_name option of the ld64 linker at link time of the library.

Please read

• install_name_tool(1),
• ld64(1), section "Options when creating a dynamic library (dylib)" and
• dyld(1), section "DYLD_LIBRARY_PATH", especially the part where is says what DYLD_LIBRARY_PATH is supposed to do: "It allows you to test new versions of existing libraries."

[moo@…]

Replying to cal@…:

• dyld(1), section "DYLD_LIBRARY_PATH", especially the part where is says what DYLD_LIBRARY_PATH is supposed to do: "It allows you to test new versions of existing libraries."

Thanks for the info. I was unaware of the install_name_tool, and we should be able to make use of that in our build process. Even so, it strikes me as odd that the new gcc doesn't seem to honor the DYLD_LIBRARY_PATH. We may be able to change our workflow to accommodate this, but it would be nice to know if this is an intentional feature of gdb 7.x. I'll do some digging around on the gdb site.

[davydden@…]

Replying to cal@…:

It is not necessary to set DYLD_LIBRARY_PATH in this case. If you ensure the binary you are running contains the correct absolute path of the library it will work just fine without DYLD_LIBRARY_PATH set. To do this, use install_name_tool -change on the binary, or ensure the libraries you link against contain the correct absolute path to themselves as the ID load command (the first line printed in otool -L output) before linking the binary. You can change the ID using install_name_tool -id or using the -install_name option of the ld64 linker at link time of the library.

this is far from being optimal. I am running executables which are linked against total of some 20 libraries (which are also liked one against another). Some with full path, some with just library names. This never bothered me since I had DYLD_FALLBACK_LIBRARY_PATH set up correctly and thus executable always run fine.

I just spent some several hours to actually trace this problem starting from Eclipse not working in parallel debug mode for my application. I really hope this is not a "feature" of the new gdb...

[davydden@…]

Cc Me!

[cooljeanius (Eric Gallager)]

Cc Me!

[mf2k (Frank Schima)]

dweber has retired. See #43834.

[mf2k (Frank Schima)]

#53744

[raimue (Rainer Müller)]

I don't see any action that could be taken by MacPorts. If gdb still has problems with DYLD_LIBRARY_PATH, please raise this issue upstream.