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 - d...@des.no _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool