[MacPorts] #41749: GGDB gives: dyld: Library not loaded @rpath/libCore.so
#41749: GGDB gives: dyld: Library not loaded @rpath/libCore.so -------------------------+-------------------------------- Reporter: alkulakov@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.1 Keywords: | Port: -------------------------+-------------------------------- 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 -- Ticket URL: <https://trac.macports.org/ticket/41749> MacPorts <http://www.macports.org/> Ports system for OS X
#41749: gdb: dyld: Library not loaded @rpath/libCore.so --------------------------+---------------------- Reporter: alkulakov@… | Owner: dweber@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.1 Resolution: | Keywords: Port: gdb | --------------------------+---------------------- Changes (by ryandesign@…): * cc: ryandesign@… (added) * owner: macports-tickets@… => dweber@… * port: => gdb Old description:
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
New description: 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 -- Comment: 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. -- Ticket URL: <https://trac.macports.org/ticket/41749#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X
#41749: gdb: dyld: Library not loaded @rpath/libCore.so --------------------------+---------------------- Reporter: alkulakov@… | Owner: dweber@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.1 Resolution: | Keywords: Port: gdb | --------------------------+---------------------- Comment (by alkulakov@…): Replying to [comment:1 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? -- Ticket URL: <https://trac.macports.org/ticket/41749#comment:2> MacPorts <http://www.macports.org/> Ports system for OS X
#41749: gdb: dyld: Library not loaded @rpath/libCore.so --------------------------+---------------------- Reporter: alkulakov@… | Owner: dweber@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.1 Resolution: | Keywords: Port: gdb | --------------------------+---------------------- Comment (by ryandesign@…): Here's one article that explains @rpath: http://www.dribin.org/dave/blog/archives/2009/11/15/rpath/ -- Ticket URL: <https://trac.macports.org/ticket/41749#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X
#41749: gdb: dyld: Library not loaded @rpath/libCore.so --------------------------+---------------------- Reporter: alkulakov@… | Owner: dweber@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.1 Resolution: | Keywords: Port: gdb | --------------------------+---------------------- Comment (by 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) }}} -- Ticket URL: <https://trac.macports.org/ticket/41749#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X
#41749: gdb: dyld: Library not loaded @rpath/libCore.so --------------------------+---------------------- Reporter: alkulakov@… | Owner: dweber@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.1 Resolution: | Keywords: Port: gdb | --------------------------+---------------------- Comment (by cal@…): Replying to [comment:4 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." -- Ticket URL: <https://trac.macports.org/ticket/41749#comment:6> MacPorts <http://www.macports.org/> Ports system for OS X
#41749: gdb: dyld: Library not loaded @rpath/libCore.so --------------------------+---------------------- Reporter: alkulakov@… | Owner: dweber@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.1 Resolution: | Keywords: Port: gdb | --------------------------+---------------------- Comment (by moo@…): Replying to [comment:6 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. -- Ticket URL: <https://trac.macports.org/ticket/41749#comment:7> MacPorts <http://www.macports.org/> Ports system for OS X
#41749: gdb: dyld: Library not loaded @rpath/libCore.so --------------------------+---------------------- Reporter: alkulakov@… | Owner: dweber@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.1 Resolution: | Keywords: Port: gdb | --------------------------+---------------------- Comment (by davydden@…): Replying to [comment:6 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... -- Ticket URL: <https://trac.macports.org/ticket/41749#comment:8> MacPorts <http://www.macports.org/> Ports system for OS X
#41749: gdb: dyld: Library not loaded @rpath/libCore.so --------------------------+-------------------------------- Reporter: alkulakov@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.1 Resolution: | Keywords: Port: gdb | --------------------------+-------------------------------- Changes (by mf2k@…): * owner: dweber@… => macports-tickets@… Comment: dweber has retired. See #43834. -- Ticket URL: <https://trac.macports.org/ticket/41749#comment:11> MacPorts <http://www.macports.org/> Ports system for OS X
#41749: gdb: dyld: Library not loaded @rpath/libCore.so --------------------------+------------------------------- Reporter: alkulakov@… | Owner: stuartwesterman@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.1 Resolution: | Keywords: Port: gdb | --------------------------+------------------------------- Changes (by mf2k@…): * owner: macports-tickets@… => stuartwesterman@… -- Ticket URL: <https://trac.macports.org/ticket/41749#comment:12> MacPorts <http://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts