can't open dynamic library
can't open dynamic library
- Subject: can't open dynamic library
- From: Dan Korn <email@hidden>
- Date: Fri, 27 Jun 2008 16:32:30 -0500
I'm building a plug-in bundle (A), which links to a dynamic library
(B), which in turn links to another dynamic library (C). All the
libraries are intended to be included in the plug-in's bundle. The
first dynamic library (B) links just fine, but when I try to link the
main plug-in (A), I get a "can't open dynamic library" warning about
the second dynamic library (C), and none of the symbols in the first
dynamic library (B) are found, so the link fails.
Here's the message:
/Xcode2.5/usr/bin/../libexec/gcc/i686-apple-darwin8/4.0.1/ld:
warning can't open dynamic library: /Xcode2.5/SDKs/MacOSX10.4u.sdk/
Library/Frameworks/libwx_mac_u_d.dylib referenced from: /Projects/
FusionPro-mainline/FusionProWorkspace/FusionProMac/FusionPro/
FPUnicodeUI/build/Debug/Default/fpunicodeui_macho_d.dylib (checking
for undefined symbols may be affected) (No such file or directory,
errno = 2)
Where fpunicodeui_macho_d.dylib is "B" and libwx_mac_u_d.dylib is
"C". "B" is my own library I'm building, and "C" is a third-party
library.
Here are the results from running otool on the intermediate dynamic
library (B):
>otool -L fpunicodeui_macho_d.dylib
fpunicodeui_macho_d.dylib:
/usr/local/lib/fpunicodeui_macho_d.dylib (compatibility version
1.0.0, current version 1.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
(compatibility version 2.0.0, current version 128.0.0)
@executable_path/../Frameworks/JS.framework/Versions/A/JS
(compatibility version 1.0.0, current version 1.0.0)
/Library/Frameworks/libwx_mac_u_d.dylib (compatibility version
2.8.0, current version 2.8.6)
@executable_path/../Frameworks/WASTE.framework/Versions/A/WASTE
(compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 88.3.9)
Obviously the second library (libwx_mac_u_d.dylib, or "C") is not
actually at "/Library/Frameworks/", but it's also surely not at "/
Xcode2.5/SDKs/MacOSX10.4u.sdk/Library/Frameworks/", from whence the
main project (A) says it's looking for it.
I'm not sure I understand the philosophy behind this. The library (B)
to which I'm trying to link is fully built. I can understand that at
*run time* I need to have all the libraries in the right places, but
why does the entire dynamic loading tree have to be satisfied at *link
time*? All that the linker should care about, as far as I know, is
whether the library I'm linking to exports the functions it needs,
right? The intermediate library (B) links just fine, and finds the
other library (C) from where I'm telling the linker to find it, even
though it isn't at the path it needs to be at run time, so why does
whatever is linking to it (A) care about that? Shouldn't the linker
just link, and let the dynamic loader do its thing at run time to make
sure the dynamic libraries and their functions are actually loaded?
I do have a Run Script step which uses install_name_tool at the end of
the build of the main plug-in (A), which resets all the paths to its
various dylibs and frameworks to @loader_path or @loader_path/../
Frameworks, so that they can be embedded in the plug-in's bundle
without having to install things to other folders. I can also do this
for the intermediate plug-in (B), so the path to the other dylib (C)
becomes "@loader_path/libwx_mac_u_d.dylib", but then the linker gives
me, "warning can't open dynamic library: @loader_path/
libwx_mac_u_d.dylib", which I have no idea how to resolve. What does
"@loader_path" resolve to while I'm linking?
So, what can I do to get this all to link properly? Should I create a
"dummy" library with the same exported functions, but without the
dependencies on other libraries, just to link, and swap out the "real"
library when I make the bundle for my plug-in? Should I have a Run
Script step to copy all the libraries to "/Library/Frameworks/" or "/
Xcode2.5/SDKs/MacOSX10.4u.sdk/Library/Frameworks/" or
"@loader_path" (wherever the linker thinks that is)? Do I need to
write some late-binding code to load the function pointers at run time
instead of linking them? (Note that I can't use "@rpath" as far as I
know, that only works on Leopard, but the plug-in needs to run on
Tiger as well.)
Thanks,
Dan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden