[LLVMdev] proposal to avoid zlib dependency.

[Óscar Fuentes]

Reid Kleckner <rnk at google.com> writes:

>> It is a good thing that LLVM works when zlib is not present, but
>> assuming that LLVM will not support certain zlib-related features
>> "because it is Windows" just shows how much misinformation some people
>> have about that OS.
>
> I haven't heard of anyone doing this successfully,

Why should people advertise such successful usage of zlib on
LLVM/Windows?

> and there isn't any
> documentation, which is just a hair shy of being unsupported.

Again, why should Windows be different on this aspect? zlib works fine
on Windows, the build systems are expected to detect it...

> I agree,
> though, we can fix this. If GnuWin32 provides a usable zlib, that's great,
> we should document how to use it.

Adding documentation about how to get zlib can be useful for those users
who are not familiarized with the environment, but simply mentioning
that some LLVM features (such as compressing DWARF info) will benefit
from the presence of zlib would be enough.

>> It probably works on MinGW, but then you're a MinGW binary in a MinGW
>> > world.
>>
>> I think you are confusing MinGW with Cygwin. There is nothing special
>> about MinGW binaries. Moreover, for C code the libraries are compatible.
>> I've been using the same zlib binary on both MinGW(-w64) and MSVC for a
>> decade, across multiple toolset releases.
>>
>
> I did mean MinGW, I was really just referring to the C++ ABI, alternative
> SDK headers, and CRT adapters.

I don't understand why you mention that using MinGW puts you on another
world, as if it where something that fundamentally separated you from
those that use MSVC.

>> The "MinGW world" vs the "VS world" is restricted to C++, where
>> different ABIs are used by their respective compilers. That's nothing
>> new on Windows, which doesn't has a "platform C++ ABI" (nor Linux has,
>> because C++ has no special role on neither OS.) C++ compilers with
>> incompatible C++ ABIs are common on Windows. Actually, a MSVC++ version
>> is often incompatible with other versions.
>
>
> There are proposals to define such a platform C++ ABI for Windows, N4028:
> https://isocpp.org/blog/2014/05/n4028
>
> It's not clear to me that the ISO C++ standard is the right place to
> declare that, but it suggests that Microsoft (or at least Herb) intend to
> document the Visual C++ ABI.

That's not what I get from that proposal. It is about a generic C++ ABI,
not tied to any specific platform. Windows is mentioned as an example.
In any case it doesn't mention that Windows (the OS, rather of the
MSVC++ toolset) will care about that ABI at all.