[Top][All Lists]
[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: |
Mon, 21 Dec 2009 18:21:35 +0200 |
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?