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

[Evgeny Grin]

21.04.2014, 02:50, "JonY" <address@hidden>:
> 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?
Thanks for idea. Do you always have enough volunteers to get all tasks done? :)

>>>  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.
Win32 dll processing is good designed. You will never have any problem at 
runtime with multiple functions with same name from different modules. They are 
isolated, just like local static variables.

> 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.
Unfortunately ld currently do not support "--no-export-all-symbols" (but 
dlltool does support).
So I need to patch ld first. Don't think that special case dll-building with 
dlltool will be accepted for libtool code. :)

>>  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.
What's the trouble?
If you don't blindly use "--export-all-symbols" (either implicitly or 
explicitly) you will never have any trouble on win32.