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
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
