Hello Matěj, * Matěj Týč wrote on Wed, Oct 27, 2010 at 10:44:25PM CEST: > I have came across a libtool issue that complicates my life quite much. > The essence of the problem is that libtool refuses to make a DLL if it > is supposed to link a static library into the DLL. I have learned that > this is a good assumption since the majority static libs don't contain > PIC code, which would not work at all in the library. [...] > The trouble is that in this very case, it is OK to link with libuuid.a, > because it contains data only. However libtool doesn't want to link with > it no matter what.
Also, w32 COFF essentially doesn't produce different code for shared libraries. > The situation is described in more detail in the link below by people > who understand the stuff more: > http://mingw-users.1079350.n2.nabble.com/undefined-ref-of-win32-function-with-mingw32msvc-td1089772.html > So now the question is: What to do now? Maybe the mingw project is > wrong? No, I don't think so. > Or maybe it can be checked somehow whether a static library > contains data only so it can be linked without problems? Maybe that. Since libuuid seems to be fairly special, I don't have any problem with special-casing it (as we already do for -lc -lm and maybe a couple of other libraries). OTOH, if the w32 maintainers agree, then we can also give in and allow linking against static libraries plainly. I tried the trivial patch (set deplibs_check_method to pass_all) a while ago but that caused a number of test failures, so somebody would at least have to look into this issue. Thanks for the report, Ralf _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
