libtool
[Top][All Lists]
Advanced

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

Re: Disable --whole-archive when using convenience archives


From: Alon Bar-Lev
Subject: Re: Disable --whole-archive when using convenience archives
Date: Thu, 7 Jan 2010 10:07:46 +0200

On Mon, Dec 21, 2009 at 6:21 PM, Alon Bar-Lev <address@hidden> wrote:
> On Thu, Dec 3, 2009 at 10:39 PM, Ralf Wildenhues <address@hidden> wrote:
>> * Alon Bar-Lev wrote on Thu, Dec 03, 2009 at 09:28:59PM CET:
>> > On Thu, Dec 3, 2009 at 10:17 PM, Ralf Wildenhues wrote:
>> > > * Alon Bar-Lev wrote on Thu, Dec 03, 2009 at 07:08:03PM CET:
>> > > > I have some convenience archives linked against several modules.
>> > > >
>> > > > I wish only required objects to be included in modules.
>> > >
>> > > Then make the convenience archives not be convenience archives any
>> > > longer, i.e., make them libtool libraries.
>> [...]
>> > > In either case, they may end up being shared libraries (or both), so if
>> > > you don't want that, add -static to libbar_la_LDFLAGS.
>> >
>> > I had to add -prefer-pic to CFLAGS in order it to work properly... :)
>> >
>> > Wow... this is an ugly workaround... Any reason why a simple switch to
>> > "libtool --mode=link" is not supported?
>>
>> Yes, I think this is by intention.  What you do is, at least most of the
>> time, ugly.  Why do you need the library to be PIC?  Usually, the reason
>> for that is that lib1.la does end up included in a, or a couple of, shared
>> libraries or modules somewhere.  And at that point, you risk (exposing
>> your users to) subtle bugs: if code from lib1 is present in several
>> places, and contains static state (example: last random number of a
>> RNG), then on some systems, different parts of the running executable
>> might suddenly use different instances of that state.  Eww.
>>
>> Typically, that's the point at which developers reconsider to make lib1
>> a proper shared library.
>>
>> > Is it the first time someone needs this?
>>
>> No, but we've been able to convince most of the other guys that asked
>> for this to reconsider.  ;-)
>
> Hello Ralf,
>
> For some strange reason this workaround does not work in Windows when
> creating a DLL.
>
> I get:
> ---
> /bin/sh ../../../../libtool --tag=CC   --mode=link
> x86_64-w64-mingw32-gcc  -g -O2 -pedantic -Wall -Wextra  -module
> -shared -avoid-version -no-undefined -export-symbols x.exports -o x.la
> -rpath /tmp/xxx/lib x.lo ../../../../src/lib/core/libcore.la -lws2_32
>
> *** Warning: This system can not link to static lib archive
> ../../../../src/lib/core/libcore.la.
> *** I have the capability to make that library automatically link in
> when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have.
> *** But as you try to build a module library, libtool will still create
> *** a static module, that should work as long as the dlopening application
> *** is linked with the -dlopen flag to resolve symbols at runtime.
> ---
>
> If I modify libtool:
> if test "$deplibs_check_method" != pass_all; then
> To:
> if false && test "$deplibs_check_method" != pass_all; then
>
> It works...
>
> Any ideas?
>

Hello Ralf,

Any idea how to workaround/solve this on windows host?

Thanks!




reply via email to

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