On 04 October 1999, Michael P. Reilly said:
Whoops, I totally forgot to mention the other potentially useful feature I added this weekend. Now, entries in the 'libraries' list can include a directory component, which will tell the compiler interface to instruct the C compiler to look only in that directory for that particular library.
This can lead to some real problems. When given a shared object, most link editors (ld) will use that exact pathname to find the object at runtime, ignoring the -R (-rpath) and LD_LIBRARY_PATH (LIB_PATH) variables. The system had better determine when and how shared objects (.sl/.so) should be handled differently from archive files (.a). Also, considering that most testing is handled in the build environment (with those same pathnames), this type of problem might not be found until after installation.
Hmmm, good point -- I hadn't considered this possibility.
One possible "solution" (ahem) is to make the "libraries with a directory component" feature only look for static libraries. If you want to use a shared library, it had better work with -l/-L/-R.
This is, I think, compatible with the two uses I see for this feature. The first use is how I demonstrated in pil_setup.py -- just link in a C library built for and with this extension module. In that case it'd be silly to make the C library shared, as we're building a shared object to load at runtime anyway. No point in having a small .so with the Python glue, which then loads a large .so with all the real C code. Just load one .so with both of them.
The other use is to appease Paul Dubois and anyone else using the Distutils as a local build tool: Paul needs to be sure that he links with a specific development version of some library. Again, I don't see it as a big loss to say "if you want to link with library foo in /some/devel/dir, then it had better be a static library".
Comments? Windows/DLL perspectives?