Issue 18024: dbm module fails to build on SLES11SP1 using 2.7.5 source (original) (raw)

Issue18024

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/dbm.so /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libgdbm.so when searching for /usr/lib/libgdbm.so /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: cannot find /usr/lib/libgdbm.so collect2: ld returned 1 exit status
msg189692 - (view) Author: Kristofer Wempa (wempa) Date: 2013-05-20 20:47
Some more information: The libndbm.so 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/libgdbm.so /usr/lib/libgdbm_compat.so ) 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/libgdbm.so. 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!
History
Date User Action Args
2022-04-11 14:57:45 admin set github: 62224
2020-04-26 17:04:27 zach.ware set status: open -> closednosy: + zach.waremessages: + resolution: out of datestage: resolved
2013-05-20 20:47:05 wempa set messages: +
2013-05-20 20:11:50 wempa create