site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Forwarding from Nick: libauto.dylib doesn't exist on 10.3 but does exist in 10.4's SDK Nick _______________________________________________ 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... 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. This email sent to site_archiver@lists.apple.com