barry@zope.com (Barry A. Warsaw) writes:
Basically what you have in cvs works great, except for one small necessary addition. If you build Berkeley DB from source, it's going to install it in something like /usr/local/BerkeleyDB.3.3 by default. Why they choose such a bizarre location, I don't know.
The problem is that unless your sysadmin hacks ld.so.conf to add /usr/local/BerkeleyDB.X.Y/lib onto your standard ld run path, bsddbmodule.so won't be linked in such a way that it can actually resolve the symbols at run time. I don't think it's reasonable to require such system hacking to get the bsddb module to link properly, and I think we can do better.
Here's a small patch to setup.py which should fix things in a portable way, at least for *nix systems. It sets the envar LD_RUN_PATH to the location that it found the Berkeley library, but only if that envar isn't already set.
I dislike that change. Setting LD_RUN_PATH is the jobs of whoever is building the compiler, and should not be done by Python automatically. So far, the Python build process avoids adding any -R linker options, since it requires quite some insight into the specific installation to determine whether usage of that option is the right thing. If setup.py fails to build an extension correctly, it is the adminstrator's job to specify a correct build procedure in Modules/Setup. For that reason, I rather recommend to remove the magic that setup.py looks in /usr/local/Berkeley*, instead of adding more magic. Regards, Martin