[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