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$|/%{libdirname}| ;  \
        /LDFLAGS/ s|LDFLAGS=|LDFLAGS= -L. |'    \
    ./Makefile.pre.in.old >Makefile.pre.in

The "DIR=" is for an x86_64 bug that installs Python to
the wrong directory (/usr/lib instead of /usr/lib64).

I tried building Py2.5 by hand (configure/make) and
that also works nicely.

I attached a patch that fixes the problems I encountered.

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=324500

Seems to be fixed in 2.5b3.

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.

Please open a new bug for the /usr/lib64 issue.