[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: |
Mon, 21 Apr 2014 06:49:50 +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 09:22, Evgeny Grin wrote:
>
>
> 19.04.2014, 04:45, "JonY":
>> On 4/19/2014 03:31, Evgeny Grin wrote:
>>> 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.
>
> Of course cleaning is required, but it's not always possible to simple
> rebuild some particular lib on Win32.
> But I was talking about ability to link static in shared.
>
This is relevant, it is what kicked off the discussion. How about a
tighter reign over what gets contributed instead of randomly accepting
executable code?
>> 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.
>
> Right, it's nice idea to prevent static link for shared lib that blindly use
> "--export-all-symbols". But for well-designed libs that use dllexport
> attribute or def-file disallowing static libs is just obstacle.
>
You have to remember, using static libs with shared DLLs in itself is a
bad idea, you still end up with *multiple* instance of it at runtime as
well, even if it is not exported, moving the problem from link time to
run time.
Above all, --export-all-symbols is default behavior in the absents of
any dllexport attributes or def files, so yes, blocking static libraries
is justified without introducing PE specific scanning rules.
>>> 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.
>
> Ok, I got the advantage of libtool, but still don't understand why this
> should prevent linking static libs in well-designed shared lib?
>
Your best option is either go entirely static or DLLs only. Going
somewhere in between is just plain trouble on Windows.
signature.asc
Description: OpenPGP digital signature