[me]

So: is this true? Does a static library under Windows need to be built with library and library search directories? Or is this an unnecessary appendage that can be jettisoned?

[Jim Ahlstrom]

AFAIK, Windows is just like Unix. You specify a list of libraries to use to find undefined symbols. In Unix you add "-lsomething" to the linker command line, and in Windows you add "something.lib" to a list.

No no, I'm talking about *building* a library, not about using one. I.e. when you bundle *.obj together into foo.lib, do you need to tell the tool-that-creates-foo.lib what libraries the code in *.obj depends on and where to find those libraries? Under Unix, it goes like this: cc -c foo1.c foo2.c foo3.c # create *.o ar -cr libfoo.a foo1.o foo2.o foo3.o and with MSVC++'s command-line interface, I gather it's something sorta-kinda-vaguely like this: cl /c /Tcfoo1.c /Fofoo1.obj # repeat three times link foo1.obj foo2.obj foo3.obj /OUT:foo.lib HOWEVER, the code that does this in Distutils adds other libraries to this mix. My question: is this necessary? Does the MSVC++ linker need to know how to resolve symbols in *.obj *when it bundles them together into a static library*? If so, this affects the CCompiler interface; currently, MSVCCompiler and UnixCCompiler are inconsistent, and I want to fix that. The question is, do I add unused 'libraries' and 'library_dirs' args to the UnixCCompiler link-a-static-lib method, or do I remove them from the corresponding MSVCCompiler method? Perry Stoll, author of the original code, seems to think that removing the library options from MSVCCompiler's 'link_static_lib()' is OK, so that's what I'm inclined to do. I just want to make sure I'm not misunderstanding what it means to build a static library with MSVC++. Greg -- Greg Ward - Unix weenie gward@python.net http://starship.python.net/~gward/ BE ALERT!!!! (The world needs more lerts ...)

Greg Ward wrote:

No no, I'm talking about *building* a library, not about using one.

Oh, sorry.

Under Unix, it goes like this:

cc -c foo1.c foo2.c foo3.c # create *.o ar -cr libfoo.a foo1.o foo2.o foo3.o

and with MSVC++'s command-line interface, I gather it's something sorta-kinda-vaguely like this:

cl /c /Tcfoo1.c /Fofoo1.obj # repeat three times link foo1.obj foo2.obj foo3.obj /OUT:foo.lib

Well, no. AFAIK "link" can create only executables or DLL's, not libraries. Note that, despite the name, a Dynamic Link Library is very much like an executable and not much like a Unix static lib. To create libraries under Windows, use the lib program: lib.exe /OUT:libfoo.lib foo1.obj foo2.obj foo3.obj Only the Windows "Great Unwashed" pay attention to this. Normal Windows people use the development environment. In particular this makes it easy to use lengthy lists of *.obj's instead of libraries. JimA

On 09 March 2000, James C. Ahlstrom said:

Well, no. AFAIK "link" can create only executables or DLL's, not libraries. Note that, despite the name, a Dynamic Link Library is very much like an executable and not much like a Unix static lib.

To create libraries under Windows, use the lib program: lib.exe /OUT:libfoo.lib foo1.obj foo2.obj foo3.obj

A-ha! I've just had one of those minor revelations that comes only after months of being totally blind to the painfully obvious: I named the method wrong. It should be 'create_static_lib()', not 'link_static_lib()'. There... it's fixed: renamed and rewritten to use "lib.exe", not refer to any other libraries, and be consistent with the CCompiler API. Here's what it's supposed to do (docstring from ccompiler.py): """Link a bunch of stuff together to create a static library file. The "bunch of stuff" consists of the list of object files supplied as 'objects', the extra object files supplied to 'add_link_object()' and/or 'set_link_objects()', the libraries supplied to 'add_library()' and/or 'set_libraries()', and the libraries supplied as 'libraries' (if any). 'output_libname' should be a library name, not a filename; the filename will be inferred from the library name. 'output_dir' is the directory where the library file will be put. 'debug' is a boolean; if true, debugging information will be included in the library (note that on most platforms, it is the compile step where this matters: the 'debug' flag is included here just for consistency).""" And here's the new implementation in msvccompiler.py: def create_static_lib (self, objects, output_libname, output_dir=None, debug=0, extra_preargs=None, extra_postargs=None): (objects, output_dir) = \ self._fix_link_args (objects, output_dir, takes_libs=0) output_filename = \ self.library_filename (output_libname, output_dir=output_dir) if self._need_link (objects, output_filename): lib_args = objects + ['/OUT:' + output_filename] if debug: pass # XXX what goes here? if extra_preargs: lib_args[:0] = extra_preargs if extra_postargs: lib_args.extend (extra_postargs) self.spawn ([self.link] + ld_args) else: self.announce ("skipping %s (up-to-date)" % output_filename) # create_static_lib () ('self.link' is the full path to link.exe, found by scouring the registry for DevStudio... or it's just "link.exe" if we didn't find DevStudio in the registry, eg. if we don't have registry access modules available.) OK, just fixed the build_clib command... and PIL still builds fine (PIL, and distributions like it that include a C library, is the whole point of this exercise). Greg -- Greg Ward - "always the quiet one" gward@python.net http://starship.python.net/~gward/ UFO's are for real: the Air Force doesn't exist.