Re: SDKs and linking
Re: SDKs and linking
- Subject: Re: SDKs and linking
- From: Paul Forgey <email@hidden>
- Date: Tue, 23 Nov 2004 14:54:38 -0800
DYLD_LIBRARY_PATH may help you get there, but it won't completely solve
the problem.
Let's say you have app which dynamically links to lib1 which links to
lib2. lib1 and lib2 are in /that/directory although they have dylib
names in /usr/lib.
Setting DYLD_LIBRARY_PATH to include /that/directory will let the app
link to lib1 without -L or -F, but it still won't find lib2. You can
include both libraries in -l. While that's a pain to do because you
have to anticipate the entire dependency graph, it might be easier than
what you are doing now.
On Nov 23, 2004, at 2:30 PM, Sam Vaughan wrote:
The same problem exists in 10.3 with the Developer SDKs. Substitute
all mention of 10.4 with 10.3 and 10.3 with 10.2 if you like.
Sam
On 24/11/2004, at 9:24 AM, Shawn Erickson wrote:
On Nov 23, 2004, at 1:51 PM, Sam Vaughan wrote:
Forwarding from Nick:
Hi,
I am trying to build some things on 10.3 using the 10.4 SDK, and
the behaviour of ld is making life difficult. It seems that
implicitly linked libraries do not honour -L paths (even if -Z is
passed), hence, a program which links in libSystem.dylib will fail
to link. eg:
$ gcc -Z -L/Developer/SDKs/MacOSX10.4.0.sdk//usr/lib
-F/Developer/SDKs/MacOSX10.4.0.sdk//System/Library/Frameworks -o
bin-10.4.0/XVMprobe obj-10.4.0/mac_probe.o -framework
CoreFoundation -framework IOKit
ld: warning can't open dynamic library: /usr/lib/libauto.dylib
(checking for undefined symbols may be affected) (No such file or
directory, errno = 2)
ld: Undefined symbols:
_auto_register_weak_reference referenced from CoreFoundation
expected to be defined in /usr/lib/libauto.dylib
_auto_unregister_weak_reference referenced from CoreFoundation
expected to be defined in /usr/lib/libauto.dylib
<...snip...>
_utrans_openU referenced from CoreFoundation expected to be defined
in libicucore
libauto.dylib doesn't exist on 10.3 but does exist in 10.4's SDK
What is the proper solution to this? Explicitly linking the
libraries will work, but that's a large number of potentially
changing libraries. Alternatively (and the solution I've taken so
far), I can do something like this:
$ gcc -Z -L/Developer/SDKs/MacOSX10.4.0.sdk//usr/lib -dylib_file
/usr/lib/libauto.dylib:/Developer/SDKs/MacOSX10.4.0.sdk//usr/lib/
libauto.dylib -dylib_file
/usr/lib/libobjc.A.dylib:/Developer/SDKs/MacOSX10.4.0.sdk//usr/lib/
libobjc.A.dylib -dylib_file
/usr/lib/libicucore.A.dylib:/Developer/SDKs/MacOSX10.4.0.sdk//usr/
lib/libicucore.A.dylib
-F/Developer/SDKs/MacOSX10.4.0.sdk//System/Library/Frameworks -o
bin-10.4.0/XVMprobe obj-10.4.0/mac_probe.o -framework
CoreFoundation -framework IOKit
which does work, but is very ugly... and I'm concerned over the
amount of work needed to maintain the dylib_file list.
The base of this problem stems from full paths being stored in the
libraries. It would be better to have an independent search path,
ala LD_LIBRARY_PATH for runtime and -L for link time.
Mac OS X 10.4 (Tiger) is under NDA and is not to be discussed on any
public lists.
You may want to contact Apple's DTS folks about how best to go about
this at this time.
-Shawn
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden