Re: mingw-w64's libuuid.a : *** Warning: linker path does not have real file for library -luuid.

[Peter Rosin]

On 2012-07-22 04:00, JonY wrote:
> On 7/22/2012 00:43, Peter Rosin wrote:
>> On 2012-07-21 14:49, Vincent Torri wrote:
>>> On Sat, Jul 21, 2012 at 2:41 PM, Peter Rosin <address@hidden> wrote:
>>>> On 2012-07-21 13:16, Vincent Torri wrote:
>>>>> absolutely NO reason to add to the linker static libraries that are
>>>>> ONLY used in my Evil library and that are not used elsewhere.
>>>>>
>>>>> I think that it is the best solution
>>>>
>>>> That disables (easy) static linking. I, as a library author, do not
>>>> like to make that policy decision for the application author.
>>>
>>> on Windows  DLL are good. I already pass --disable-static to all my
>>> Windows builds.
>>
>> That has been argued elsewhere, but I can still see the value of the
>> other side. So again, I, as a library author, do not like to shove that
>> policy decision down the throat of my library consumers.
> 
> So how are you supposed to build it if *I* want it as a DLL?
> 
> Rhetoric notwithstanding, how are you supposed to build a DLL that uses
> libuuid.a? No, cloning UUID constants is not a proper fix.

By not using Libtool, I suppose, or by mucking about with Libtool
internals.

Libtool needs to change to handle this situation cleanly. I don't know
how. Care should perhaps be taken so that libtool doesn't export stuff
from static libraries such as libuuid though, since the DLL consumer
could be using libuuid as well without knowing that some consumed DLL
is also pulling it in.

Cheers,
Peter