On 9/3/2010 7:59 AM, Peter Rosin wrote: > So, I'm now proposing this naming scheme instead: > > static lib: foo.lib > shared lib: foo-2.dll > import lib: foo.dll.lib > > which is a lot more consistent with the MinGW naming, i.e.: > > static lib: libfoo.a > shared lib: libfoo-2.dll > import lib: libfoo.dll.a
The only reason MinGW could do this, is that when we developed the cygmingw naming scheme, we simultaneously updated both gcc and ld to understand the new names, and imposed a search order: For instance, when ld is called with the argument `-lxxx' it will attempt to find, in the first directory of its search path, libxxx.dll.a xxx.dll.a libxxx.a xxx.lib cygxxx.dll (*) libxxx.dll xxx.dll before moving on to the next directory in the search path. (*) Actually, this is not `cygxxx.dll' but in fact is `<prefix>xxx.dll', where `<prefix>' is set by the `ld' option `--dll-search-prefix=<prefix>'. This way, non-libtool unixish makefiles could always use -lfoo, regardless of whether they were linking to a static lib or dynamic lib. We can't similarly change the behavior of cl.exe -- unless you want to build THAT logic into the `compile' script (or is there a `linker' script)? > On the negative side we have: > > * Inconsistent naming of import libs when comparing with other MSVC > libraries. They are typically named as the static lib, but so are > static libs, when that's what's shipped. Pick your poison. Right. So anybody who uses libtool to build a core library, but then wants to build an application (which doesn't use libtool) that links against that DLL, will have to modify their makefile rules to say -lfoo.dll. Really, what this means is that non-libtool clients of libfoo will have to put detection machinery (in autoconf?) to determine whether libfoo.a or libfoo.dll.a exists; Makefile.in will have to use a subst variable so that either -lfoo or -lfoo.dll is specified in the Makefile... This would include most of libtool's own built-in tests, I would think. Unless `compile'/`linker' becomes a lot smarter, and abstracts all that. (Actually, now that I think about this some more, modifying these scripts to implement search rules is probably a bad idea; they need to implement the SAME search rules as the underlying tool (cl.exe in this case), otherwise you'd get inconsistent results. So, scratch that idea). > Besides, it's better to do this now, before the > first release of libtool with MSVC support, than after. Well, that's true. I have some misgivings about this plan, but you know best. -- Chuck