libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MSW DLLs support in libtool


From: Evgeny Grin
Subject: Re: MSW DLLs support in libtool
Date: Sat, 13 Feb 2016 21:23:47 +0300
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 13.02.2016 4:56, Vadim Zeitlin wrote:
>  Thanks, it's an interesting case and I didn't think about it. However
> while it's true that bad things can/will happen in this case, wouldn't they
> also happen if two DLLs link with the different versions of the same DLL?
> It's not totally clear how would you set things up to make the build pick
> two different versions of a static library, but  presumably the same could
> be done for the import libraries too. Of course, only one DLL would be
> effectively loaded into the process address space (unless you have two
> import libraries with the same name corresponding to the DLLs with
> different names, and if we're considering really perverse cases, why not?),
> but one or the other DLL linking with it will crash if the two versions are
> not ABI-compatible.
Yes, this is the real problem. Kodi for Windows uses a lot of DLLs. Some
of sources of those DLLs a little outdated and require specific other
libs. Mostly used libs are zlib, libiconv and openssl. We have to use
all those libs as DLLs, but they are not always ABI compatible. So it's
a process of try-and-fail when combining all DLLs into working set. Life
will be much simpler if many of those libs will be statically linked
into DLLs.

> PR> If libtool should be in the business of protecting from such disasters
> PR> is another matter...
> 
>  I don't think it should and I don't think it can. And I'm also pretty sure
> that the current protection against this is, first, unintentional (because
> there are surely more direct ways to check for this) and, second, if we
> accept that forbidding linking with static libraries completely is worth
> this protection in Windows DLL case, then it logically follows that we
> should just never link with static libraries at all. And this is (luckily,
> I don't want to give anybody any ideas...) not what libtool does.
> 
>  So I still think that the check for PIC dependencies under Windows is
> useful. Do you, or anybody else, believe it is and can anybody think of any
> practical example when it would be useful?
I think it's time for sending patches. With keeping in mind backward
compatibility.

- -- 
Best Wishes,
Evgeny Grin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWv3SzAAoJEL96xKXqwrr0c5YH/jjpJBLXHjCV7VBpvXpTe8zi
AdMUHMibsdNEEvLq5IepWcMNCuC+h4efPQe7DcE6O7GKauCwqsoWhf+YUyfTJLV9
zLV6kv76q3lQIfsZYGJUq07iCYMdBSlSemZEAcrArFWNnMnutTUv1v8URKNlWuzy
AfueMVjYty2s3S3cg3boAOjDcqKjw132iljXxPTrkC8SHoEsGlSqHJJbWQ1ecjZJ
05q0IHn+SM2l5mI8fRRIqsHznq4PIZ5Vq9jHU5iTk7Zq1PTha/6IWoXjHt7TEqv5
ntG+OBJ5UPMU+7KdhNlTCEIeF+O/fuziqCf5+CflH3weY+512kE4BaPTjBTfG3E=
=2upu
-----END PGP SIGNATURE-----



reply via email to

[Prev in Thread] Current Thread [Next in Thread]