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

[Evgeny Grin]

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?

> 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.