"MvL" == Martin v Loewis
writes:
MvL> I dislike that change. Setting LD_RUN_PATH is the jobs of MvL> whoever is building the compiler, and should not be done by MvL> Python automatically. So far, the Python build process avoids MvL> adding any -R linker options, since it requires quite some MvL> insight into the specific installation to determine whether MvL> usage of that option is the right thing. Really? You know the path for the -R/--rpath flag, so all you need is the magic compiler-specific incantation, and distutils already (or /should/ already) know that. MvL> If setup.py fails to build an extension correctly, it is the MvL> adminstrator's job to specify a correct build procedure in MvL> Modules/Setup. For that reason, I rather recommend to remove MvL> the magic that setup.py looks in /usr/local/Berkeley*, MvL> instead of adding more magic. I disagree. While the sysadmin should probably fiddle with /etc/ld.so.conf when he installs BerkeleyDB, it's not documented in the Sleepycat docs, so it's entirely possible that they haven't done it. That shouldn't stop Python from building a perfectly usable module, especially because it really can figure out all the necessary information. Is there some specific fear you have about compiling in the run-path? Note I'm not saying setting LD_RUN_PATH is the best approach, but it seemed like the most portable. I couldn't figure out if distutils knew what the right compiler-specific switches are (i.e. "-R dir" on Solaris cc if memory serves, and "-Xlinker -rpath -Xlinker dir" for gcc, and who knows what for other Unix or <gasp> Windows compilers). -Barry