libtool
[Top][All Lists]
Advanced

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

Re: DLL creation and static libs


From: Ralf Wildenhues
Subject: Re: DLL creation and static libs
Date: Tue, 2 Nov 2010 07:14:48 +0100
User-agent: Mutt/1.5.20 (2010-08-04)

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



reply via email to

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