Re: Xcode 2.5 on Leopard: trouble with -isysroot and friends
Re: Xcode 2.5 on Leopard: trouble with -isysroot and friends
- Subject: Re: Xcode 2.5 on Leopard: trouble with -isysroot and friends
- From: Ken Thomases <email@hidden>
- Date: Fri, 23 May 2008 06:06:31 -0500
On May 21, 2008, at 1:25 PM, Ken Thomases wrote:
On May 21, 2008, at 12:54 PM, Chris Espinosa wrote:
Could you dig up or reproduce the linker invocation that created
libXcursor.dylib? Perhaps by using relative paths (rather than
absolute paths into your build folder) or by postprocessing with
install_name_tool might do the trick.
So, you're suggesting that libXcursor.dylib should be made dependent
on merely "libXrender.1.dylib" rather than "/Users/ken/work/cxmac/
x11r6/image/X11/lib/libXrender.1.dylib"? Or maybe "@loader_path/
libXrender.1.dylib" would work?
Unfortunately, neither of those approaches work. Rather than
continuing to refer to libXcursor and libXrender, etc., I'll use the
simpler example from my bug report. Here's what I submitted in my bug
report:
Steps to Reproduce:
1. Install Xcode 2.5 on Leopard
2. Set your PATH so that /Xcode2.5/usr/bin and /Xcode2.5/usr/sbin are
early in the path, prior to /usr/bin and /usr/sbin.
3. cd /tmp
4. Create a dynamic library /tmp/libbar.dylib:
4a. echo "char bar(void){return 0;}" > bar.c
4b. gcc -isysroot /Xcode2.5/SDKs/MacOSX10.4u.sdk -o libbar.dylib -
dynamiclib bar.c -install_name /tmp/libbar.dylib
5. Create a dynamic library /tmp/libfoo.dylib which depends on /tmp/
libbar.dylib:
5a. echo "char bar(void); char foo(void){return bar();}" >foo.c
5b. gcc -isysroot /Xcode2.5/SDKs/MacOSX10.4u.sdk -o libfoo.dylib -
dynamiclib foo.c -L/tmp -lbar -install_name /tmp/libfoo.dylib
6. Create a program which links against libfoo.dylib:
6a. echo "char foo(void); int main(void){return foo();}" >test.c
6b. gcc -isysroot /Xcode2.5/SDKs/MacOSX10.4u.sdk -o test test.c -L/tmp
-lfoo
Suppose I insert a step 5c:
5c. install_name_tool -change /tmp/libbar.dylib libbar.dylib
libfoo.dylib
So that "otool -L libfoo.dylib" gives this:
libfoo.dylib:
/tmp/libfoo.dylib (compatibility version 0.0.0, current version 0.0.0)
libbar.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 88.3.9)
Now, step 6b superficially succeeds. It creates a "test" executable.
However, that program only works if libbar.dylib is in the current
working directory at run-time. For example, if I add a step 7 which
is "./test", it works, but if I add a step 8 which is "cd; /tmp/test",
it fails because it can't find libbar.dylib in my home directory.
Using @loader_path is a non-starter. If instead of the above step 5c,
I use the similar alternative:
5c. install_name_tool -change /tmp/libbar.dylib @loader_path/
libbar.dylib libfoo.dylib
then step 6b fails because the linker doesn't understand
@loader_path. Only the dynamic linker seems to understand that.
Hopefully there are other possible workarounds. Any suggestions?
Thanks in advance,
Ken
_______________________________________________
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