Unix tool. Compiling on Leopard, deploying on Tiger, using Python

[Christiaan Hofman]

You're right, it does not change the install name, only the library it  
links to. The install name itself comes from the linked python  
library. You can change the install name using the install_name_tool,  
so you should use that.

I am not an expert on linking, so be aware I may be wrong here. But I  
think you have 2 choices. Either change the install name in the python  
library. You can do that in the stub library. If you don't want to  
affect other projects you could make another version of the python  
library with your preferred install name and link to that (either  
build it from source or make a copy with the changed install name). Or  
you can change the install name of the python library in your  
executable, using an extra script build phase.

HTH,
Christiaan

On 13 Jun 2008, at 3:22 PM, Gerben Wierda wrote:

> On Jun 8, 2008, at 12:37 PM, Christiaan Hofman wrote:
>
>> Have you tried adding an -dylib_file option to OTHER_LD_FLAGS?
>
> I added -dylib_file=/System/Library/Frameworks/Python.framework/ 
> Versions/2.5/Python:/usr/lib/libpython2.dylib to the link command  
> via configure (the OTHER_LD_FLAGS is for XCode projects), but what  
> happens is:
>
> /bin/sh ../libtool --mode=link gcc -mmacosx-version-min=10.4 - 
> dylib_file=/System/Library/Frameworks/Python.framework/Versions/2.5/ 
> Python:/usr/lib/libpython2.dylib -L/usr/local/lib -L/sw/lib -o  
> fontforge \
> 	    startnoui.o stamp.o exelibstamp.lo ../libfontforge.la -rpath / 
> usr/local/lib   ../libgutils.la ../libgunicode.la    -lpython2.5 - 
> liconv -Wl,/System/Library/Frameworks/CoreServices.framework/ 
> CoreServices  -lpthread  -lm
> gcc -mmacosx-version-min=10.4 -dylib_file=/System/Library/Frameworks/ 
> Python.framework/Versions/2.5/Python:/usr/lib/libpython2.dylib - 
> o .libs/fontforge startnoui.o stamp.o .libs/exelibstamp.o -Wl,/ 
> System/Library/Frameworks/CoreServices.framework/CoreServices  -L/ 
> usr/local/lib -L/sw/lib ../.libs/libfontforge.dylib /usr/local/src/ 
> fontforge-20080429/.libs/libgutils.dylib ../.libs/libgutils.dylib / 
> usr/local/src/fontforge-20080429/.libs/libgunicode.dylib ../.libs/ 
> libgunicode.dylib -lpython2.5 /usr/lib/libiconv.dylib -lpthread -lm
>
> And otool tells me:
>
> hermione-a:pfaedit gerben$ otool -L /usr/local/Build/i386/pfaedit/ 
> usr/local/bin/fontforge
> /usr/local/Build/i386/pfaedit/usr/local/bin/fontforge:
> 	/System/Library/Frameworks/CoreServices.framework/Versions/A/ 
> CoreServices (compatibility version 1.0.0, current version 32.0.0)
> 	/usr/local/lib/libfontforge.1.dylib (compatibility version 2.0.0,  
> current version 2.0.0)
> 	/usr/local/lib/libgutils.1.dylib (compatibility version 2.0.0,  
> current version 2.1.0)
> 	/usr/local/lib/libgunicode.3.dylib (compatibility version 4.0.0,  
> current version 4.0.0)
> 	/System/Library/Frameworks/Python.framework/Versions/2.5/Python  
> (compatibility version 2.5.0, current version 2.5.1)
> 	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current  
> version 7.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current  
> version 111.1.1)
> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current  
> version 1.0.0)
>
> In other words, I can tell it to use /usr/lib/libpython2.dlib but  
> that does get translated to the actual file (/usr/lib/libpyton2.dlib)
>
> G
>
>>
>> Christiaan
>>
>> On 8 Jun 2008, at 9:03 AM, Gerben Wierda wrote:
>>
>>> OK, here is my problem. I want to create a binary (compiled from  
>>> open source on Leopard) that works on both Tiger and Leopard, so  
>>> backward compatible. Most of the time, this is no problem, but now  
>>> it is. I compile and link the binary by giving this to configure:
>>>
>>> 				CFLAGS="-mmacosx-version-min=10.4"
>>> 				LDFLAGS="-mmacosx-version-min=10.4"
>>>
>>> which normally is all I have to do. But now I have a binary that  
>>> uses Python. And though python is available in /usr/lib as symlink
>>>
>>> $ ls -l /usr/lib/*pyth*
>>> lrwxr-xr-x  1 root  wheel  16 Dec 31 13:21 /usr/lib/ 
>>> libpython.dylib -> libpython2.dylib
>>> lrwxr-xr-x  1 root  wheel  16 Dec 31 13:21 /usr/lib/ 
>>> libpython2.5.dylib -> libpython2.dylib
>>> lrwxr-xr-x  1 root  wheel  68 Dec 31 13:21 /usr/lib/ 
>>> libpython2.dylib -> ../../System/Library/Frameworks/ 
>>> Python.framework/Versions/2.5/Python
>>> lrwxr-xr-x  1 root  wheel  75 Dec 31 13:31 /usr/lib/python2.5 - 
>>> > ../../System/Library/Frameworks/Python.framework/Versions/2.5/ 
>>> lib/python2.5
>>>
>>> the resulting binary is linked hard against the python 2.5  
>>> library. Basically, at this stage I do not care if it is compiled  
>>> and linked against 2.5 and when run on Tiger it is running against  
>>> 2.3 (which may give problems).
>>>
>>> The resulting library is linked against
>>>
>>> 	/System/Library/Frameworks/Python.framework/Versions/2.5/Python  
>>> (compatibility version 2.5.0, current version 2.5.1)
>>>
>>> which is not avaiable on Tiger and not against
>>>
>>> 	/usr/lib/libpython2.dylib
>>>
>>> which is.
>>>
>>> Is there a way to tell the binary to link against /usr/lib/ 
>>> libpython2.dylib and not have it turn that into the actual 2.5 lib  
>>> in /System?
>>>
>>> Thanks,
>>>
>>> G
>>> _______________________________________________
>>> MacOSX-dev mailing list
>>> MacOSX-dev at omnigroup.com
>>> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>>
>