site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com 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: libauto.dylib doesn't exist on 10.3 but does exist in 10.4's SDK _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... 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. 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 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 This email sent to site_archiver@lists.apple.com