[Pythonmac-SIG] Module build fails because distutils adds "-isysroot"

[Ronald Oussoren]

On 30 Sep, 2009, at 11:30, Patrick Näf wrote:

> Hi folks
>
> I'm currently writing a very simple Python module in C that provides  
> an
> interface to libaprutil's MD5 routines. I compile my module using
> distutils, as per instructions in the "Building C and C++ Extensions  
> with
> distutils" chapter of the official Python docs.
>
> Since Mac OS X has libaprutil pre-installed, it seems natural that I  
> try
> to use the system version of the library. My Python module's .c file
> therefore contains the following #include directive:
>
>  #include <apr-1/apr_md5.h>
>
> Everything works fine (module compiles and I can use it) as long as  
> I use
> the system version of Python (2.5.1) to compile the module. The  
> problem is
> that I *really* need to build the module with Python 2.6 or newer, and
> this is where my trouble starts. I have Python 3.1.1 installed in
> /Library/Frameworks/Python, and with this version of Python my  
> module's
> build fails miserably, like this:
>
> tharbad:~ patrick$
> /Library/Frameworks/Python.framework/Versions/3.1/bin/python3.1 ./ 
> setup.py
> build_ext --inplace
> running build_ext
> building 'aprmd5' extension
> gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk
> -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3
> -I/Library/Frameworks/Python.framework/Versions/3.1/include/ 
> python3.1 -c
> aprmd5.c -o build/temp.macosx-10.3-fat-3.1/aprmd5.o
> aprmd5.c:43:60: aprmd5.c:43:60: error: apr-1/apr_md5.h: No such file  
> or
> directory
> [...]
>
> The problem here is that the gcc option "-isysroot" moves the root for
> system includes to the SDK directory (/Developer/SDKs/ 
> MacOSX10.4u.sdk),
> away from the normal root (/). Unfortunately, the SDK does not  
> contain the
> header <apr-1/apr_md5.h>, which causes the build to fail. Where does
> "-isysroot" come from? Not from my module, it's added automatically by
> distutils.
>
> I believe I have correctly diagnosed the problem, and I can  
> certainly work
> around it *somehow* in my module, but since I am rather new to  
> Python I
> have trouble deciding on a solution that is appropriate. I am  
> therefore
> writing to this list, hoping someone reading this can give me some  
> advice.
>
> 1) Is my problem a known situation for which there is a generally
> accepted, best-practice solution? If so, a pointer in the right  
> direction
> would be most welcome. If not, what would seem to be a good  
> solution? Make
> my own build of libaprutil using the MacOSX10.4u SDK? Rely on a
> third-party build of libaprutil (e.g. fink)? Force the compiler to  
> use the
> system's libaprutil?

The OSX installers are build to explicitly use the 10.4u SDK. That's  
mostly done to ensure that people on OSX 10.4 can build extensions out  
of the box.

Python 2.6.3 (just released) contains some code that automaticly  
disables usage of the SDK when it is not present.

You can disable usage of the 10.4u SDK by adding the following  
arguments to the definition of your Extension in setup.py:

	 extra_compile_args=['-isysroot', '/'],  extra_link_args=['- 
isysroot', '/']

Ronald