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

[Christiaan Hofman]

BTW, unless you build your own version of libpython to link against, this
may still not work. The reason is that install_name_tool does not change the
compatibility version of the library, which therefore remains 2.5.0. So
Tiger's version 2.3 would still not link, now because the dlopen deems it
too old. Unfortunately I don't know how to change that part. I guess there's
some other tool around to do that, but I never could find any myself. I
would like to have it though, as I run into problems there when linking the
libiconv library, which has incompatible versions on Leopard and Tiger. So
if anyone could add this piece of the puzzle, I would also be grateful.

Christiaan

On Fri, Jun 13, 2008 at 5:23 PM, Christiaan Hofman <cmhofman at gmail.com>
wrote:

> 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
>
>
>
>
>