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
_______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
