Understanding libtool on Windows / MinGW

[Dag-Erling Smørgrav]

I am currently porting a largish piece of software from Linux to
Windows, and I'm having trouble compiling some of the third-party
libraries it requires.

(before you ask: yes, I have to compile most of these libraries myself;
this is not the issue here.)

I realize that this comes up regularly, but I haven't found a unified,
coherent explanation or solution.  I am asking these questions not just
to find a solution to my immediate problem, but to find the *correct*
solution (as opposed to all the wrong ones Google dug up for me), and to
truly *understand* why it is the correct one.

Let's start with the first indication I had that something was not as it
should be.  While building the C++ bindings for HDF5 (after fixing a few
other bugs), I got this:

  libtool: link: g++ -o .libs/dsets.exe dsets.o h5cpputil.o  
../../test/.libs/libh5test.a ../../c++/src/.libs/libhdf5_cpp.a 
/mingw/lib/gcc/mingw32/4.4.0/libstdc++.dll.a ../../src/.libs/libhdf5.a -lws2_32 
-L/mingw/lib/gcc/mingw32/4.4.0
  g++.exe: C:/MinGW/lib/gcc/mingw32/4.4.0/libstdc++.dll.a: No such file or 
directory

First question: why is libtool linking *explicitly* against libstdc++?
I noticed that configure decided that this was necessary, but the first
thing I did after installing MinGW was compile "hello world" programs in
C, C++ and Fortran, and gcc / g++ / gfortran had no trouble linking them
without explicit references to libc / libstdc++ / libgfortran.

Second question: there is no libstdc++.dll.a; is this a mistake on the
part of the MinGW maintainers?

Third question: what are the expected library names when building with
the GNU toolchain on Windows?  I expected ".a" for the static library,
".dll" for the shared library and ".lib" for the import library.
Apparently, I was wrong.

(I probably knew this at some point, but it's been ten years since I did
any serious development work on Windows, and back then, I used an IDE
that did it all for me)

Fourth question: when I googled for solutions to this problem, what I
found (again and again) was "replace library_names='whatever.dll.a' in
the .la file with library_names=''".  Somehow, I don't think libtool
would consistently set library_names to an incorrect value; if it had at
some point, surely it would have been fixed by now.  Therefore, that
advice must be incorrect.  This hypothesis was strengthened when I found
that jpeg7 won't link with this hack (not as in "libtool fails to link
programs that use libjpeg", but as in: libtool fails to link libjpeg")

Fifth question: can someone give a concise explanation of what, exactly,
-no-undefined does, and why it is required?

DES
-- 
Dag-Erling Smørgrav - address@hidden