[Top][All Lists]

[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: Wed, 10 Feb 2016 23:27:13 +0300
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

Hash: SHA256

On 10.02.2016 6:29, Bob Friesenhahn wrote:
> On Wed, 10 Feb 2016, Vadim Zeitlin wrote:
>> Sorry but this is just not true for the MSW DLLs. If the libtool user
>> tries to build a DLL, you can safely assume that it will not have
>> undefined
>> symbols. Anything else just doesn't make sense because it would always
>> result in an error. Again, this is different from the traditional Unix
>> shared libraries.
> Why do you say this?  Most software built using libtool still comes from
> Unix type systems.  Without the existing behavior it would be difficult
> to take a program developed on a Unix type system and just compile it
> under Windows.  It is thought that errors are bad and successful
> compilation is good.
Do you mean creating static libs when shared lib was requested instead
of failing?
In this case errors are good, because requested operation was not
performed. Any when some program later failed to compile/run, it's much
harder to find source of problem because was no indication of failed
shared lib creation. Moreover, some libs designed to be compiled as
shared lib, may not function properly if used as static. Especially if
DllMain() is used. In this case it will be even more harder to find
what's wrong even if some program that uses lib is compiled and run.

That's look a bit weird. It's like I compiled something for ARM64, but
compiler generated code for ARM, because compiler not sure that ARM64
code can be generated (and even didn't try to generate ARM64 code).
Same libtool does for shared and static libs.

Version: GnuPG v2


reply via email to

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