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: dbm module fails to build on SLES11SP1 using 2.7.5 source
Type: compile error Stage: resolved
Components: Build Versions: Python 2.7
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: wempa, zach.ware
Priority: normal Keywords:

Created on 2013-05-20 20:11 by wempa, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (3)
msg189687 - (view) Author: Kristofer Wempa (wempa) Date: 2013-05-20 20:11
I recently built a new version of our Linux tools using Python 2.7.5 on our SLES11SP2 server.  Afterwards, I noticed that the dbm module was not built successfully.  The Python build did not fail and the failed module build summary at the end of the build did not list "dbm", which surprised me.  I rebuilt Python and captured the actual error when attempting to build the dbm module.  Below is the error.  I managed to get it to build by replacing "-lndbm" with "-lgdbm".  This is the first time dbm has failed to build on this platform.  I've built several versions of Python 2.7.2, 2.7.3 and 2.7.4 and this module built every single time.  Something that has changed in the build process is causing this problem.

Link Error:

gcc -pthread -shared build/temp.linux-x86_64-2.7/nfs/statbuild/ci1admin/ci1_toolchain_src/KRIS/Python-2.7.5/Modules/dbmmodule.o -L/usr/lib -L/lib -L/usr/x86_64-suse-linux/lib -L/lib64 -L/usr/lib64 -L/usr/local/lib -lndbm -o build/lib.linux-x86_64-2.7/
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/ when searching for /usr/lib/
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: cannot find /usr/lib/
collect2: ld returned 1 exit status
msg189692 - (view) Author: Kristofer Wempa (wempa) Date: 2013-05-20 20:47
Some more information:

The is not a library but some sort of ld script.  It has the following content:

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
GROUP ( /usr/lib/ /usr/lib/ )

What I think is happening is that the build is finding the one in /usr/lib instead of /usr/lib64 and then it's trying to load the incomptaible /usr/lib/  I was also able to circumvent the problem by setting LDFLAGS to "-L/usr/lib64 -L/lib64".  This put the 64-bit library directories earlier on the link line.
msg367318 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2020-04-26 17:04
As 2.7 has now reached EOL, I'm going to go ahead and close the issue.  Sorry this never got attention, but I'm glad you found a workaround!
Date User Action Args
2022-04-11 14:57:45adminsetgithub: 62224
2020-04-26 17:04:27zach.waresetstatus: open -> closed

nosy: + zach.ware
messages: + msg367318

resolution: out of date
stage: resolved
2013-05-20 20:47:05wempasetmessages: + msg189692
2013-05-20 20:11:50wempacreate