Nick Bastin

Ok, really that should be 2.6.4 and 2.7.1a1, but I’d imagine this problem might exist for more than just those versions. I haven’t tried to build 3.x.

I don’t quite know the exact steps that produce this problem (maybe any/all configure option?), but if you do:

./configure --enable-shared

as is my wont to do, Python happily builds and then barfs all over building modules, something like:


building '_struct' extension
gcc -shared build/temp.freebsd-5.3-RELEASE-i386-2.6/u1/Python/Python-2.6.4/Modules/_struct.o -L/usr/local/lib -lpython2.6 -o build/lib.freebsd-5.3-RELEASE-i386-2.6/_struct.so
/usr/bin/ld: cannot find -lpython2.6
building '_ctypes_test' extension
gcc -shared build/temp.freebsd-5.3-RELEASE-i386-2.6/u1/Python/Python-2.6.4/Modules/_ctypes/_ctypes_test.o -L/usr/local/lib -lpython2.6 -o build/lib.freebsd-5.3-RELEASE-i386-2.6/_ctypes_test.so
/usr/bin/ld: cannot find -lpython2.6

….ad nauseum….

This is because the compiler isn’t looking for where your python2.6 library currently is (even worse if you have a 2.6 in /usr/local/lib and it has different options than the one you’re currently building) – which is in your current working directory (‘.’). The hackish fix to the problem is to edit setup.py in the build root, and add in detect_modules:

add_dir_to_list(self.compiler.library_dirs, '.')


Do this *after* the line to add /usr/local/lib, so that (perhaps non-intuitively) -L. comes before -L/usr/local/lib on the compile command line.

Now if you rebuild everyone will be happy. There may be some sufficient CFLAGS or LDFLAGS jank to set in your environment that has the same effect, but you shouldn’t have to do this – Python ought to know where to find the library it just built if it needs it for further build machinery.