Re: can't open dynamic library
Re: can't open dynamic library
- Subject: Re: can't open dynamic library
- From: Jeffrey Oleander <email@hidden>
- Date: Sun, 29 Jun 2008 08:21:20 -0700 (PDT)
> On Fri, 2008/06/27, Dan Korn <email@hidden> wrote:
> From: Dan Korn <email@hidden>
> Subject: can't open dynamic library
> To: "Xcode Users" <email@hidden>
> Date: Friday, 2008 June 27, 16:32
> 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...
> /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)
> 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)
I've been seeing a lot of similar messages to the group
that seem to be due to a lack of clarity and mnemonic
value in the naming of certain settings.
* There's the place where a library or framework gets
written when it's built.
* There are the places where another app or library or
framework goes to look for unresolved symbols in
libraries or frameworks.
And there seems to be at least two places or settings
that determine the latter.
Just to add to the confusion, there's the problem of
how to tell library A to resolve it's symbols from
libraries B and C, but not D or E.
Names for different kinds of path specifications have
been mentioned like @rpath and @executable_path but
other than r probably signifying "relative" (relative
to what?) they give me, at lease, no clue about whether
these are directions for where something (library,
framework, app) should be written or where to try to
find something.
I mention this, because I'm hoping that one good
post that clarifies these things (and clarification
in the docs) will reduce the amount of related traffic
or lead to ideas for enhancement requests to reduce
such problems in the future.
at
http://developer.apple.com/releasenotes/DeveloperTools/RN-Id/
I see
The -rpath option allows you to embed a path in an executable [which] dyld will use on 10.5 and later to locate @rpath based dependent dylibs
What's an "@rpath based dependent dylib"?
and here
http://developer.apple.com/releasenotes/DeveloperTools/RN-dyld/
I see
Traditionally on Mac OS X dependent libraries are specified with an absolute path (e.g. /usr/lib/libSystem.B.dylib). The dyld in Mac OS X 10.5 now supports “run path relative” library paths. There is two parts to using this functionality. The first part is to build a dylib with an install name that starts with @rpath/ (e.g. @rpath/libfoo.dylib). Any clients that link with that dylib with then have run path relative load path to the dylib. The second part is specifying the list of directories that dyld should search to resolve run path relative load paths. This is done with the linker option -rpath dir. The dir path can be an absolute path or start with@loader_path/ and be relative to the executable containing the rpath.
Typical usage is that run path relative framework Foo would have a install name of “@rpath/Foo.framework/Versions/A/Foo”, and a dylib foo would have a run path relative path of “@rpath/libfoo.dylib”. Then the main executable which will need to load these would be linked with one or more -rpath options. If all the run path relative frameworks and dylibs are to be contained within an application .app directory, then the -rpath directories would start with @loader_path.
http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachOTopics/Articles/loading_code.html
You can locate private frameworks and shared libraries in an application package using a relative-path install name beginning with @executable_path, such as @executable_path/../Frameworks/MyFramework.framework. This is useful for sharing functionality with plug-ins (bundles)...
Listing 2 demonstrates how to create a private framework -- that is, a framework located in an application package. Specify the install name explicitly during the linking phase and prefix it with @executable_path. The install name of the resulting framework is @executable_path/../Frameworks/Bliss.framework/Versions/A/Bliss.
http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Tasks/CreatingFrameworks.html
Using a Single Xcode Project For Both Targets
The configuration for your framework target involves telling it where it will be installed. The framework needs this information so that it can find the resources it needs. Because frameworks are typically installed in fixed locations, you normally specify the full path to the appropriate frameworks directory. When you embed a framework inside a bundle, however, the location of the framework is not fixed, so you have to use the @executable_path place-holder to let the framework know its location is relative to the current executable.
Open an inspector for your framework target and select the Build tab.
Set the value of the Installation Directory build setting to @executable_path/../Frameworks.
At build time, Xcode builds your framework and puts the results in the build directory. Before the application can use the framework, however, you must configure the application target as follows:
You need to copy the framework into the application’s bundle.
You need to link the application against the framework.
You need to create a build dependency between the framework and application...
http://developer.apple.com/documentation/DeveloperTools/Conceptual/DynamicLibraries/Articles/DynamicLibraryDesignGuidelines.html
Executable-relative location. To specify a file path relative to the location of the main executable, not the referencing library, place the @executable_path macro at the beginning of the path. For example, in an application package that contains private frameworks (which, in turn, contain shared libraries), any of the libraries can locate an application resource called MyImage.tiff inside the package by specifying the path @executable_path/../Resources/MyImage.tiff. Because @executable_path resolves to the binary inside the MacOS directory in the application bundle, the resource file path must specify the Resources directory as a subdirectory of the MacOS parent directory (the Contents directory). For a detailed discussion of directory bundles, see Bundle Programming Guide.
Library-relative location. To specify a file path relative to the location of the library itself, place the @loader_path macro at the beginning of the pathname. Library-relative location allows you to locate library resources within a directory hierarchy regardless of where the main executable is located.
But that provides hardly any clarification at all.
_______________________________________________
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