Using Misc/RPM/python-2.5.spec, Python 2.5b2 fails to compile into an RPM on my machine (SuSE 10.1, AMD64, gcc 4.1). Unlike with b1, I get loads of errors saying: "ld: cannot find -lpython2.5" The funny thing is that it continues to build and only fails at the end when collecting the files for the RPM. I use configure --enable-shared --enable-unicode=ucs4 \ --enable-ipv6 --with-pymalloc --prefix=/usr \ --libdir=/usr/lib64 The shared library is correctly built before these errors come up. The error appear on the "sharedmods" target. I also tried setting LD_LIBRARY_PATH by hand, although the build script sets it before starting to build the modules - no help. What *does* help is adding "-L." to the LDFLAGS in Makefile.pre.in: sed -e '/DIR=.*lib$/ s|/lib$
Logged In: YES user_id=324500 There is a deeper issue here: Dynamic extensions fail to link until after libpython2.5.so.1.0 is installed. The '-L.' flag is the better approach to fixing this bug, but perhaps it should use the full path name, like the LD_LIBRARY_PATH environment variable used when running setup.py. Unfortunately, this bug is hidden from people compiling on top of an earlier 2.5 installation, where the link step will find and use the old library; for others, it is resolved in installation, where make will happily link the extensions if they failed to link earlier, right after installing the library. However, it means that the dynamic libraries are unavailable between the build and install steps. One major result is that the test suite refuses to run at that time. It also means that 'make install' can cause the linker to be called, which is generally discouraged.
Logged In: YES user_id=313935 The linking is fixed in 2.5b3. However, the /usr/lib64 problem remains. Python is installed to lib64 on my AMD64 machine, but the import mechanism keeps looking in /usr/lib.
