libtool
[Top][All Lists]
Advanced

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

Re: Creating shared and static libraries with convenience libraries


From: Charles Wilson
Subject: Re: Creating shared and static libraries with convenience libraries
Date: Sun, 28 Jun 2009 18:48:11 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666

Bob Friesenhahn wrote:
> On Sun, 28 Jun 2009, Charles Wilson wrote:
>>
>> So, when we get around to linking the actually installable library, both
>> the DLL and the "static' archive contain the same .o's -- the ones
>> compiled with the "pic" flags -DDLL_EXPORT and -DPIC.
>>
>> This is a problem, because now the "static" archive contains
>> declspec(dllexport)-decorated symbols.

It might also be an issue if you use -DPIC to determine whether to use
gcc-4.x's visibility specifiers, for non-win32.  Not sure about that, tho.

I've verified that this behavior (pulling in the .libs/.o's into the
"static" archive, when convenience libs are used) also occurs with
1.5.x. As it happens, liblzma itself does not export any data items, so
in MY mingw 3.4.5 builds I don't actually see the problem.  However,
Lasse does see it in his mingw 4.4.0 builds, and this seems to be the
reason.

> Interesting.  I think that it is assumed that "PIC" code will work in a
> static archive.  Apparently this is a wrong assumption for "decorated"
> DLL code.  Most open source projects ported to Windows rely on GCC's
> automatic DLL import feature.

Unless you're using MinGW to build a DLL (that exports data items?), and
is intended for use with MSVC.  Or your name is Bruno, and you don't
like auto-import:
http://www.haible.de/bruno/woe32dll.html

>> (b) I can work around it by avoiding convenience archives entirely, and
>> using subdir objects instead.  However, I'm unsure which released
>> automake version first *successfully* supported those...I know they were
>> introduced in 1.9, but IIRC proper operation required a patch that
>> wasn't merged until 1.10.  Is my recollection correct?
> 
> I know that I used it successfully for a large non-recursive build with
> subdir objects prior to 1.10 being released.  That would have been when
> the Automake feature was still "bleeding edge".  Problems I noticed in
> those days were libtool's fault and not Automake's fault.

Thanks for the data point. It appears upstream is using 1.10 for their
distribution tarballs, so as long as they are happy to *require* 1.10 or
above (for developers who want to autoreconf), then we're good to go.

The main downside of always avoiding convenience libraries is they are
the only way to get per-object compile flags...

--
Chuck




reply via email to

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