[Distutils] Re: order on link

[Greg Ward]

[Paul, I have cc'd this to the distutils sig, because I want the
 group's input on this.  Hope this isn't too gross a violation
 of email etiquette...]

On 30 September 1999, Paul F. Dubois said:
> We are not getting anything loaded from our libraries on Linux. This
> is because on Linux the .o's have to be before any of the libraries on
> the command line. I suspect this is true on other platforms where the
> order in which everything is listed is critical.
> 
> You put the -L's -l's before the .o's.

Hmmm, so I am.  That's a bug.  The fix is trivial: see lines 225-226 of
distutils/unixccompiler.py -- just change the order of 'objects' and
'lib_opts'.  Do you know if it ever matters where "-o" comes in?
Currently, I have it last, and it could easily move too.

Will a similar change have to be made to MSVCCompiler -- i.e is it as
sensitive to order of link options as Unix compiler are?

> Should there be an emergency escape hatch where I can list the exact
> link line I want? At least while we are debugging this? Our feeling is
> that this thing is close enough that we are dying to use it.

I hope that won't be necessary.  I've added one concession-to-reality
that should partially address your needs, and have plans for another.
The first is 'extra_preargs' and 'extra_postargs' parameters to all the
link and compile methods in the compiler classes.  For command-line
driven compilers, the meaning is obvious -- just a list of strings
that's inserted at the beginning or tacked on to the end of the command
line.  That's how I deal with "def" files now -- the 'build_ext' command
looks for <name-of-extension> + ".def" in the directory of the first
source file, and tacks that onto the MSVC linker command line with
'extra_postargs'.  Works for me in theory (ie. I can generate
sensible-looking MSVC command lines on my Linux box if I lie to
Distutils and tell it it's using MSVC), but I dunno about the real
world.

For more science-fictiony cases (eg. driving a Mac compiler via whatever
Apple's protocol for launching/talking to external programs is -- got an
explanation from Jack Jansen a few weeks ago, but I forget the details),
it's not clear if these will have any meaning, but using them kinda
tosses portability out the window anyways.  I still have to expose these
options at the Distutils level -- ie. add 'extra_{cc,ld}_{pre,post}args'
to the "build info" dictionary passed from the setup script to the
'build_ext' command.  Again, using these will shoot portability to hell,
but I can certainly see where it's needed.  And you could always have
extra code in setup.py to generate them for various platforms and
thereby regain portability.

The other trick I plan is to let you qualify a library name with a
directory, so you could eg. have

  ext_modules = [('foo', {'source': [...],
                          'libraries': ['/devel/foo']})]

and be guaranteed to link with /devel/libfoo.{a,so}
(whichever the linker finds and prefers).  I have to play around a bit
to see how to make this work; I *hope*

   cc ... -Ldir1 -Ldir2 -llib1 -L/devel -lfoo -llib2 ..

will do it but I'm not sure.  If not I'll have to resolve /devel/foo to
/devel/libfoo.{a,so} in the Distutils, which reeks of touchy portability
problems.  Got any better ideas?
   
        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