Hi! Since I swapped to ar-lib and consequently updated it to allow augmenting an existing archive, I've noticed stuff like this in the testsuite logs:
libtool: link: /c/cygwin/home/peda/automake/lib/ar-lib lib cru .libs/a1.lib a1.obj a1.obj : warning LNK4006: _f1 already defined in a1.lib(a1.dll); second definition ignored The reason turns out to be a bit nasty... At one point I selected this naming: static lib: foo.lib shared lib: foo-2.dll (for major version 2) import lib: foo-2.lib However, for unversioned libraries this collapses to: static lib: foo.lib shared lib: foo.dll import lib: foo.lib Oops. The symptom is seen above. When creating the static lib, an attempt to augment the already created import lib is made, but it fails... 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 An additional benefit is that with the new naming it is possible to guess the name of the import lib when only seeing -lfoo (w/o version) so it will be possible to look for that during library search. 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. * Interface change. But libtool could not work with shared libraries without .la files before and if it has .la files from someone who has use a patched libtool with "old style" MSVC libraries, they should still work. Besides, it's better to do this now, before the first release of libtool with MSVC support, than after. So, I'm proposing this patch. The testsuite is running. Ok to push if results look sane? Cheers, Peter
