Bugs item #1522046, was opened at 2006-07-13 13:55
Message generated for change (Comment added) made by breadman
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522046&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Behnel (scoder)
Assigned to: Nobody/Anonymous (nobody)
Summary: RPM build fails for Py2.5b2
Initial Comment:
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.
----------------------------------------------------------------------
Comment By: Eric Wald (breadman)
Date: 2006-08-03 14:12
Message:
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.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522046&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
