Re: DLL creation and static libs
On 11/3/2010 12:23 PM, Matěj Týč wrote: > On 2 November 2010 13:26, Charles Wilson wrote: >> On 11/2/2010 2:14 AM, Ralf Wildenhues wrote: >> ... >> the problem is there are TWO different libuuid's. There's the one that >> is part of the win32 api, and simply contains a number of static objects >> that represent UUIDs of elements of the Windows OS. [1] Then, there's >> the unix-derived one that provides routines for *generating* new UUIDs. [2] > > I thought of the nm tool. It could be used to identify which library > is which, although AFAIK, it can't be used to generally identify > libraries that contain data only. Is that correct? Well, as long as we're special casing, we can look for a *specific* public read-only data item: nm -B libuuid.a | grep ' R _IID_IUnknown' that should only appear in the w32api version, and not in the unixy one. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: DLL creation and static libs
On 2 November 2010 13:26, Charles Wilson wrote: > On 11/2/2010 2:14 AM, Ralf Wildenhues wrote: >> ... > > the problem is there are TWO different libuuid's. There's the one that > is part of the win32 api, and simply contains a number of static objects > that represent UUIDs of elements of the Windows OS. [1] Then, there's > the unix-derived one that provides routines for *generating* new UUIDs. [2] > I thought of the nm tool. It could be used to identify which library is which, although AFAIK, it can't be used to generally identify libraries that contain data only. Is that correct? Matej ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: DLL creation and static libs
On 11/2/2010 2:14 AM, Ralf Wildenhues wrote: > 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. the problem is there are TWO different libuuid's. There's the one that is part of the win32 api, and simply contains a number of static objects that represent UUIDs of elements of the Windows OS. [1] Then, there's the unix-derived one that provides routines for *generating* new UUIDs. [2] [1] On cygwin this is /usr/lib/w32api/libuuid.a (On mingw, it's /usr/lib/libuuid.a). In both cases, it IS a static library, not an import library. [2] On cygwin, this is /usr/lib/libuuid.[a,dll.a]. To my knowledge, there is no corresponding element for mingw. So...the special casing is going to be pretty complex, because you don't want to treat cygwin's unix-derived /usr/lib/libuuid* differently than any other library, but mingw's /usr/lib/libuuid.a and cygwin's /usr/lib/w32api/libuuid.a would both need the special treatment. (FYI: we'd also need to add similar logic to binutils' ld, to special case the auto-export). -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: DLL creation and static libs
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
DLL creation and static libs
Hello, 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. However, a DLL of a project that I work on and that I would like to cross-compile using mingw32 depends on libuuid.a, which is a static library. This most likely happens to people from time to time, see the link below. http://www.linuxquestions.org/questions/programming-9/libtool-problems-building-a-shared-library-790616/ For instance, I have encountered it because the mingw32 libregex (from the gnuwin project) currently depends on it. 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. 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? Or maybe it can be checked somehow whether a static library contains data only so it can be linked without problems? I also saw that Vincento Tori got involved in a similar issue, maybe he discovered something and forgot to tell us? :-) Matej ___ http://lists.gnu.org/mailman/listinfo/libtool
