[Distutils] 2 platforms down, only Mac to go...

[Phillip J. Eby]

At 01:12 PM 1/14/2006 +0000, Michael Twomey wrote:
>When I ran the tests they all worked, but setuptools had indeed built
>a static library. Looking at the compiler output it looks like none of
>the LDSHARED or CCSHARED flags you set got used.
>
>Poking further I found that you are using the dl module to test for
>RTLD_NOW, unfortunately dl isn't present on my mac. In fact setup.py
>in python's source indicates that it isn't built at all:
>
>if (dl_inc is not None) and (platform not in ['atheos', 'darwin']):
>     exts.append( Extension('dl', ['dlmodule.c']) )
>
>I temporarily hacked my copy to always set have_rtld to True and I got
>errors when setup.py tried to use the flags.

Okay, I've changed this so that the 'dl' stuff is only done on non-Mac 
platforms, and Mac is still recognized as needing stub loaders.


>  It looks like the
>compiler has to be mentioned in the LDSHARED:

Fixed in SVN.


>Using these flags the module built fine. The otool output doesn't look
>quite right though (note how the build directory is mentioned in the
>built module, it leads to problems, see below):
>
>$ otool -L libhellolib.dylib
>libhellolib.dylib:
>         build/lib.darwin-8.4.0-Power_Macintosh-2.4/libhellolib.dylib
>(compatibility version 0.0.0, current version 0.0.0)
>         /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current
>version 92.0.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
>current version 88.1.2)
>
>$ otool -L dl-hello.so
>dl-hello.so:
>         build/lib.darwin-8.4.0-Power_Macintosh-2.4/libhellolib.dylib
>(compatibility version 0.0.0, current version 0.0.0)
>         /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current
>version 92.0.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
>current version 88.1.2)

It looks like we probably need to add "-install_name libhellolib.dylib" or 
maybe "-dylib_install_name libhellolib.dylib" to the library link step for 
hellolib, in order to get that out of there.


>When I comment out the dl stuff in the bootstrap code things look a
>lot better, the module imports and runs without problems.
>I can move the directory to something_else and it still imports fine.

Yeah, it looks like that's only because it used the build directory, 
relative to the extension's location.  :(


>If I compile and link by hand all in the single directory then I get a
>fully relocatable module free of references to the build directory.
>It's looking like the linker is building paths relative to where it's
>invoked from.

So, you're using the same options supplied by the setup script, just not 
using paths under build/?  Does it still then work with all the test cases?


>I'll see if I can tweak the flags a bit, I mightn't be able to come up
>with anything but I thought you might like the early feedback. I'm
>sure someone with more OS X linking experience than me will come up
>with better solutions.

I appreciate it!  It sounds like we might be getting close.

I wonder, though, if perhaps what's happening in the configuration that 
currently works, is that the path is being interpreted as "bundle relative" 
to the extension.  This is fine and is really what we want, but I'm not 
sure that it can be done with older Mac OSes.  I seem to recall that 
bundle-relative linking was added in 10.4?  Or was it 10.3?  I need to 
start actually *using* a Mac one of these days.  :)