[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: |
Evgeny Grin |
Subject: |
Re: Forced static lib if any depend lib is static on win32 |
Date: |
Sat, 19 Apr 2014 05:22:39 +0400 |
19.04.2014, 04:45, "JonY" <address@hidden>:
> 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.
> 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.
>> 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?