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

[Michael Twomey]

Hi again,

On 14/01/06, Phillip J. Eby <pje at telecommunity.com> wrote:
>
> 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.
>

Working for me now.

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

This too.

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

-install_name did the trick (in my manual compilation anyway). The man
page says it all:

  If this is not specified, the name specified in the -o name option
will be used.

So this worked:

gcc -Wl,-x -dynamiclib -undefined dynamic_lookup $tempdir/hellolib.o \
-install_name libhellolib.dylib -o $libdir/libhellolib.dylib

Interestingly you can use "-install_name [any_path]libhellolib.dylib"
too, so ../ and ./ combinations are accepted as well.


-dylib_install_name didn't work (which surprised me), I got this error:

  powerpc-apple-darwin8-gcc-4.0.1: libhellolib.dylib: No such file or directory

This implies that it was trying to look for libhellolib.dylib before
it was built, which is odd.

>
> >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 copied the output of distutils into a shell script and modified by
hand. Based on the comment in the man page above it was using the name
from the -o flag which is why it worked when I built manually. It
worked in 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.
>

It looks like with the libhellolib.dylib built with the "-install_name
libhellolib.dylib" does the trick. Everything works fine when I try
the various tests.

I've attached the shell script I was using to build and test for reference.

> 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.  :)
>

I think it was in 10.3 (the MACOSX_DEPLOYMENT_TARGET affects this),
I'm pretty sure it was the "-undefined dynamic_lookup" which got
introduced, which had a big impact on shared libraries in bundles. I'm
not sure how this would affect the linking stuff above, it is "used to
allow any undefined symbols to be looked up dynamically at runtime"
according to the man page.

cheers,
  Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: go.sh
Type: application/x-sh
Size: 1209 bytes
Desc: not available
Url : http://mail.python.org/pipermail/distutils-sig/attachments/20060116/8ac4dc78/attachment.sh