[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
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'.
That did the trick!
Do you know if it ever matters where "-o" comes in? Currently, I have it last, and it could easily move too.
Don't know. I doubt it. I did once run into a C compiler that had no -o option at all, however. You had to make the object file in the same directory as the source.
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?
No idea. This sensitivity varies among Unix compilers, too. That leads to the nonsense of having to list a library twice. I'm too jet lagged to think about the other things you wrote. The package is useful to us even in its new state. Thanks. The .o's get left in the directory with setup.py; should be squirreled away someplace else. To allow for building for mutiple platforms it would be nice if the build products went into a platform-specific directory, eg. build/linux2. That way when you make a bug fix on one platform you don't have to blow everything away to do the next one.
On 30 September 1999, Paul F. Dubois said:
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'.
That did the trick!
OK, I'll keep the fix for 0.11.
No idea. This sensitivity varies among Unix compilers, too. That leads to the nonsense of having to list a library twice.
Luckily, that's no problem with Distutils -- you just put it in the 'libraries' list twice, and it winds up on the command line twice. This will only handle mutual dependencies amongst libraries -- .o files are always elsewhere on the command line (because of line 225-226 in distutils/unixcompiler.py), so the system can't handle every possibility.
The .o's get left in the directory with setup.py; should be squirreled away someplace else. To allow for building for mutiple platforms it would be nice if the build products went into a platform-specific directory, eg. build/linux2. That way when you make a bug fix on one platform you don't have to blow everything away to do the next one.
Yeah, I know about that. The status quo is no worse than a Makefile.pre.in system -- Numeric's current build system just drops .o files in the current directory -- so I figured it was OK if I did that in this version. There actually need to be *two* "build" directories: one for transient files (.o), and one for permanent files to install. And you're right, both of them need to be partitioned by platform, eg. "build.platlib-i86-linux" or "build.platlib-sparc-sun-solaris". My inclination would be to leave the source directories untouched, and put all intermediate and final files in other directories that are completely under Distutils control. Anyone see problems with that approach? Also, does anybody have Python code that divines that GNU style "cpu-vendor-os" string, or something similar? sys.platform is a start, but not enough because it doesn't say anything about the CPU architecture. 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
participants (2)
-
Greg Ward
-
Paul F. Dubois