[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DLL creation and static libs

From: Charles Wilson
Subject: Re: DLL creation and static libs
Date: Tue, 02 Nov 2010 08:26:32 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20090812 Thunderbird/ Mnenhy/

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]