This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: RPM build fails for Py2.5b2
Type: Stage:
Components: Build Versions: Python 2.5
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: breadman, christian.heimes, scoder
Priority: normal Keywords:

Created on 2006-07-13 19:55 by scoder, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit
spec-orig.patch scoder, 2006-07-13 19:55 patch against Misc/RPM/python-2.5.spec that fixes the problems
Messages (5)
msg29175 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2006-07-13 19:55
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  \

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

sed -e '/DIR=.*lib$/ s|/lib$|/%{libdirname}| ;  \
        /LDFLAGS/ s|LDFLAGS=|LDFLAGS= -L. |'    \
    ./ >

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.
msg29176 - (view) Author: Eric Wald (breadman) Date: 2006-08-03 20:12
Logged In: YES 

There is a deeper issue here:  Dynamic extensions fail to
link until after 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  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.
msg29177 - (view) Author: Eric Wald (breadman) Date: 2006-08-04 20:22
Logged In: YES 

Seems to be fixed in 2.5b3.
msg29178 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2006-08-06 07:10
Logged In: YES 

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.
msg59790 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-12 05:00
Please open a new bug for the /usr/lib64 issue.
Date User Action Args
2022-04-11 14:56:18adminsetgithub: 43670
2008-01-12 05:00:23christian.heimessetstatus: open -> closed
resolution: fixed
messages: + msg59790
nosy: + christian.heimes
2006-07-13 19:55:32scodercreate