[Distutils] Oh yeah! one more feature
Greg Ward
gward@cnri.reston.va.us
Mon, 4 Oct 1999 12:28:23 -0400
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?
Greg
--
Greg Ward - software developer gward@cnri.reston.va.us
Corporation for National Research Initiatives
1895 Preston White Drive voice: +1-703-620-8990
Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913