libtool
[Top][All Lists]
Advanced

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

Re: Forced static lib if any depend lib is static on win32


From: JonY
Subject: Re: Forced static lib if any depend lib is static on win32
Date: Sat, 19 Apr 2014 08:44:55 +0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0

On 4/19/2014 03:31, Evgeny Grin wrote:
> 
> 
> 18.04.2014, 19:25, "Bob Friesenhahn" <address@hidden>:
>> For Win32 builds on my Windows system, I see that it is normal for
>> DLLs to be named according to the major interface number.  For
>> example, zlib (not created using libtool) is named "zlib1.dll" and
>> libltdl (created using libtool) is named "libltdl-7.dll".  This is not
>> as convenient as ELF versioning, but does prevent disaster.  Why is
>> this not the case for your system?
> 
> For XBMC we have 41 depend precompiled lib, 4 of them depend on zlib dll, all 
> of 4 depend on zlib1.dll, but each one on specific zlib version. And with 
> some zlib versions some of depend dlls crash.
> But it's just an example. Sometimes only a small fraction of lib functions is 
> used, so it's better and wiser to statically link only those functions for 
> shared lib and not redistribute heavy additional dll with your dll.
> There are far more possibile good uses for static libs in shared libs.
> MS dev tools allow any combinations of shared/static link, why libtool give 
> worse possible options?
> 

I think you should be cleaning house, instead of allowing random bits
and bobs to connect together. The real problem is that you have 4
incompatible versions of zlib1.dll in the first place.

Libtool is good at preventing multiple exports on win32, I have seen
disasters where zlib is exported *multiple* times in different DLLs of
the same project because the author does not know what is going on. At
least it was a compatible and same version of zlib.

>> Libtool convenience libraries do support DLL exports but this is
>> because libtool built them and so it knows how they are built.  In
>> fact, libtool convenience libraries are not used like libraries at all
>> and are simply a convenient reference to a collection of object files
>> wrapped in an archive.
> 
> Didn't see anything that prevent linking static libs in shared libs.
> Additionally libtool can track if some particular lib use 
> "dllexport"/def-files or simple export of all symbols.

The difference is that convenience are purely used build time only, they
are never ever installed. It is convenient when you have enough object
files to overrun the OS command line length limit.

I'm not sure you want convenient dlls that aren't installed, they don't
make sense.


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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