[Pythonmac-SIG] Building Python extensions in C++ with autoconf

[Bob Ippolito]

On Mar 11, 2004, at 9:25 PM, Theodore D. Sternberg wrote:

> I'm trying to extend Python with C++, i.e. build a .so that the Python
> interpreter can load.  Manually, this seems to work if I say
>
>   g++ -bundle -o foo.so <etc>
>
> However, my build system uses autoconf, automake and libtool and I'd  
> like
> to continue using them ;-)  And the trouble there is that autoconf, on  
> Mac
> OS X (Darwin 7.2.0), wants to create a .dylib, not an .so, and of  
> course
> we know that Python modules have to be .so's.  There's also the added
> problem that autoconf produces a link line with stuff like  
> "-dynamiclib",
> "-install_name" and "compatibility_version" that it seems are not  
> legal if
> you have "-bundle"  there.

I don't know autoconf, but you *really really should use distutils*.   
You wouldn't be asking this question if distutils was part of your  
build process.

Anyways, the file extension are mostly just naming convention.  Python  
needs MH_BUNDLE (linked with -bundle) object files, a dylib is a  
MH_DYLIB (linked with -dynamiclib) object file.  By convention, a ".so  
file" could be either actually, because other operating systems that  
use .so don't distinguish between dynamic libraries and plugin bundles.

-install_name and -compatibility_version (and some other flags) are  
only relevant to MH_DYLIB files.  They are used at link time to provide  
hints to the dylib runtime.  You can learn more about this in Apple's  
Mach-O documentation, and by poking around the man pages for ld, dyld,  
install_name_tool, and otool (to name a few).

Anyways, here is an example of what an ideal ld command line should  
look like for Darwin 7.0 (OS X 10.3) and later.

gcc -Wl,-F. -Wl,-F. -bundle -undefined dynamic_lookup  
build/temp.darwin-7.2.0-Power_Macintosh-2.3/src/_LaunchServices.o -o  
build/lib.darwin-7.2.0-Power_Macintosh-2.3/LaunchServices/ 
_LaunchServices.so -framework Carbon -framework CoreFoundation  
-framework ApplicationServices

Note that I'm using "-undefined dynamic_lookup" instead of "-framework  
Python".  This is on purpose, and is not the current distutils  
behavior, see http://python.org/sf/887242

-bob