proposal to avoid zlib dependency.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

proposal to avoid zlib dependency.

Christophe Duvernois
Hi

Miniz (https://code.google.com/p/miniz/ ) is very small and performant implementation of zlib compression with api compatibility and it is public domain...
Miniz can be integrated directly into the llvm source code.
So it could be a good replacement or alternative to avoid zlib dependency...

If someone is interested i can provide a patch.

Regards
Christophe


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: proposal to avoid zlib dependency.

Filip Pizlo
What is the downside of Zlib dependency?  I'm curious! :-)

-Filip

On Sep 16, 2014, at 2:45 PM, Christophe Duvernois <[hidden email]> wrote:

Hi

Miniz (https://code.google.com/p/miniz/ ) is very small and performant implementation of zlib compression with api compatibility and it is public domain...
Miniz can be integrated directly into the llvm source code.
So it could be a good replacement or alternative to avoid zlib dependency...

If someone is interested i can provide a patch.

Regards
Christophe

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: proposal to avoid zlib dependency.

Reid Kleckner-2
It might not be available, so all codepaths have to recover from zlib unavailability. For example, I don't think compressed DWARF works on Windows.

On Tue, Sep 16, 2014 at 3:21 PM, Filip Pizlo <[hidden email]> wrote:
What is the downside of Zlib dependency?  I'm curious! :-)

-Filip

On Sep 16, 2014, at 2:45 PM, Christophe Duvernois <[hidden email]> wrote:

Hi

Miniz (https://code.google.com/p/miniz/ ) is very small and performant implementation of zlib compression with api compatibility and it is public domain...
Miniz can be integrated directly into the llvm source code.
So it could be a good replacement or alternative to avoid zlib dependency...

If someone is interested i can provide a patch.

Regards
Christophe

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: proposal to avoid zlib dependency.

Bob Wilson-3
If you build with configure+make, just run configure with —disable-zlib. We do this routinely, so I’m pretty sure it works.

On Sep 16, 2014, at 3:42 PM, Reid Kleckner <[hidden email]> wrote:

It might not be available, so all codepaths have to recover from zlib unavailability. For example, I don't think compressed DWARF works on Windows.

On Tue, Sep 16, 2014 at 3:21 PM, Filip Pizlo <[hidden email]> wrote:
What is the downside of Zlib dependency?  I'm curious! :-)

-Filip

On Sep 16, 2014, at 2:45 PM, Christophe Duvernois <[hidden email]> wrote:

Hi

Miniz (https://code.google.com/p/miniz/ ) is very small and performant implementation of zlib compression with api compatibility and it is public domain...
Miniz can be integrated directly into the llvm source code.
So it could be a good replacement or alternative to avoid zlib dependency...

If someone is interested i can provide a patch.

Regards
Christophe

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: proposal to avoid zlib dependency.

Saleem Abdulrasool
On Tue, Sep 16, 2014 at 4:48 PM, Bob Wilson <[hidden email]> wrote:
If you build with configure+make, just run configure with —disable-zlib. We do this routinely, so I’m pretty sure it works.

It "works" as in it builds.  However, the support for it is disabled since zlib::compress will always return StatusUnsupported, so the debug information will just not be compressed.  Effectively, compressed DWARF is unsupported on Windows.
 
On Sep 16, 2014, at 3:42 PM, Reid Kleckner <[hidden email]> wrote:

It might not be available, so all codepaths have to recover from zlib unavailability. For example, I don't think compressed DWARF works on Windows.

On Tue, Sep 16, 2014 at 3:21 PM, Filip Pizlo <[hidden email]> wrote:
What is the downside of Zlib dependency?  I'm curious! :-)

-Filip

On Sep 16, 2014, at 2:45 PM, Christophe Duvernois <[hidden email]> wrote:

Hi

Miniz (https://code.google.com/p/miniz/ ) is very small and performant implementation of zlib compression with api compatibility and it is public domain...
Miniz can be integrated directly into the llvm source code.
So it could be a good replacement or alternative to avoid zlib dependency...

If someone is interested i can provide a patch.

Regards
Christophe

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: proposal to avoid zlib dependency.

Óscar Fuentes
Saleem Abdulrasool <[hidden email]> writes:

> On Tue, Sep 16, 2014 at 4:48 PM, Bob Wilson <[hidden email]> wrote:
>
>> If you build with configure+make, just run configure with —disable-zlib.
>> We do this routinely, so I’m pretty sure it works.
>>
>
> It "works" as in it builds.  However, the support for it is disabled since
> zlib::compress will always return StatusUnsupported, so the debug
> information will just not be compressed.  Effectively, compressed DWARF is
> unsupported on Windows.

IIUC zlib availability is tested and the library used if present. Do you
mean that LLVM does not use zlib on Windows when the library is present?

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: proposal to avoid zlib dependency.

Reid Kleckner-2
On Tue, Sep 16, 2014 at 7:47 PM, Óscar Fuentes <[hidden email]> wrote:
IIUC zlib availability is tested and the library used if present. Do you
mean that LLVM does not use zlib on Windows when the library is present?

Sure, but if there aren't instructions for how to do it easily, then it's effectively unsupported. There isn't really a canonical way to "install" headers and libraries on Windows like you would on Linux.

It probably works on MinGW, but then you're a MinGW binary in a MinGW world.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: proposal to avoid zlib dependency.

Yaron Keren
Large software libraries like OpenCV (under 3rdparty directory) do include copies of zlib and friends and build it, for that reasons. The source code is just half a megabyte and I think the license is compatible. We could do the same with zlib or  miniz.


2014-09-17 7:02 GMT+03:00 Reid Kleckner <[hidden email]>:
On Tue, Sep 16, 2014 at 7:47 PM, Óscar Fuentes <[hidden email]> wrote:
IIUC zlib availability is tested and the library used if present. Do you
mean that LLVM does not use zlib on Windows when the library is present?

Sure, but if there aren't instructions for how to do it easily, then it's effectively unsupported. There isn't really a canonical way to "install" headers and libraries on Windows like you would on Linux.

It probably works on MinGW, but then you're a MinGW binary in a MinGW world.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: proposal to avoid zlib dependency.

Joerg Sonnenberger
On Wed, Sep 17, 2014 at 12:27:42PM +0300, Yaron Keren wrote:
> Large software libraries like OpenCV (under 3rdparty directory) do include
> copies of zlib and friends and build it, for that reasons. The source code
> is just half a megabyte and I think the license is compatible. We could do
> the same with zlib or  miniz.

From a packager's perspective, library bundling is one of the most
obnoxious issues around. It creates all kind of fun whenever a security
issue is found or you have to fix the same portability issue in 100
different copies (*cough* gtest *cough*)

Joerg
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: proposal to avoid zlib dependency.

Mueller-Roemer, Johannes Sebastian
Yes, this is incredibly annoying, so please avoid that. However I noticed that the current solution using CMake is broken, as I cannot enter my own ZLIB_ROOT, since no proper find_package is used.

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
[hidden email]  |  www.igd.fraunhofer.de


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Joerg Sonnenberger
Sent: Wednesday, September 17, 2014 12:56
To: [hidden email]
Subject: Re: [LLVMdev] proposal to avoid zlib dependency.

On Wed, Sep 17, 2014 at 12:27:42PM +0300, Yaron Keren wrote:
> Large software libraries like OpenCV (under 3rdparty directory) do
> include copies of zlib and friends and build it, for that reasons. The
> source code is just half a megabyte and I think the license is
> compatible. We could do the same with zlib or  miniz.

From a packager's perspective, library bundling is one of the most obnoxious issues around. It creates all kind of fun whenever a security issue is found or you have to fix the same portability issue in 100 different copies (*cough* gtest *cough*)

Joerg
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: proposal to avoid zlib dependency.

Dan Liew
In reply to this post by Reid Kleckner-2
>> IIUC zlib availability is tested and the library used if present. Do you
>> mean that LLVM does not use zlib on Windows when the library is present?
>
>
> Sure, but if there aren't instructions for how to do it easily, then it's
> effectively unsupported. There isn't really a canonical way to "install"
> headers and libraries on Windows like you would on Linux.
>
> It probably works on MinGW, but then you're a MinGW binary in a MinGW world.

I really don't like the idea of bundling zlib. I'm not aware of LLVM
bundling any external libraries currently and I don't think now is a
good time to start. Based on what has been discussed so far it sounds
like it's "possible" to build zlib (or use a prebuilt binary) on
windows and use it within LLVM so surely the right solution is...

* Document how zlib can by LLVM on windows.
* Improve our detection of zlib. I glanced at the the CMake files and
we aren't using ``find_package(zlib)`` which surprises me. Packages
exist in CMake to abstract away the issue of finding where header
files and libraries actually live. I glanced at the implementation of
FindZLIB.cmake and it looks like it has Windows support because I see

```
# Normal search.
set(_ZLIB_SEARCH_NORMAL
  PATHS "[HKEY_LOCAL_MACHINE\\SOFTWARE\\GnuWin32\\Zlib;InstallPath]"
        "$ENV{PROGRAMFILES}/zlib"
  )
```

Thanks,
Dan.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: proposal to avoid zlib dependency.

İsmail Dönmez
On Wed, Sep 17, 2014 at 3:52 PM, Dan Liew <[hidden email]> wrote:

>>> IIUC zlib availability is tested and the library used if present. Do you
>>> mean that LLVM does not use zlib on Windows when the library is present?
>>
>>
>> Sure, but if there aren't instructions for how to do it easily, then it's
>> effectively unsupported. There isn't really a canonical way to "install"
>> headers and libraries on Windows like you would on Linux.
>>
>> It probably works on MinGW, but then you're a MinGW binary in a MinGW world.
>
> I really don't like the idea of bundling zlib. I'm not aware of LLVM
> bundling any external libraries currently and I don't think now is a
> good time to start. Based on what has been discussed so far it sounds
> like it's "possible" to build zlib (or use a prebuilt binary) on
> windows and use it within LLVM so surely the right solution is...
>
> * Document how zlib can by LLVM on windows.
> * Improve our detection of zlib. I glanced at the the CMake files and
> we aren't using ``find_package(zlib)`` which surprises me. Packages
> exist in CMake to abstract away the issue of finding where header
> files and libraries actually live. I glanced at the implementation of
> FindZLIB.cmake and it looks like it has Windows support because I see
>
> ```
> # Normal search.
> set(_ZLIB_SEARCH_NORMAL
>   PATHS "[HKEY_LOCAL_MACHINE\\SOFTWARE\\GnuWin32\\Zlib;InstallPath]"
>         "$ENV{PROGRAMFILES}/zlib"
>   )
> ```

So installing zlib from
http://gnuwin32.sourceforge.net/packages/zlib.htm should work fine.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: proposal to avoid zlib dependency.

Dan Liew
In reply to this post by Mueller-Roemer, Johannes Sebastian
On 17 September 2014 13:27, Mueller-Roemer, Johannes Sebastian
<[hidden email]> wrote:
> Yes, this is incredibly annoying, so please avoid that. However I noticed that the current solution using CMake is broken, as I cannot enter my own ZLIB_ROOT, since no proper find_package is used.

I just had a go at hacking this so that we use find_package(ZLIB) if
LLVM_ENABLE_ZLIB is used. Does the attached patch work correctly?

If so I could send to llvm-commits for review.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

use_find_package_zlib.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: proposal to avoid zlib dependency.

Óscar Fuentes
In reply to this post by Reid Kleckner-2
Reid Kleckner <[hidden email]> writes:

> On Tue, Sep 16, 2014 at 7:47 PM, Óscar Fuentes <[hidden email]> wrote:
>
>> IIUC zlib availability is tested and the library used if present. Do you
>> mean that LLVM does not use zlib on Windows when the library is present?
>
>
> Sure, but if there aren't instructions for how to do it easily, then it's
> effectively unsupported. There isn't really a canonical way to "install"
> headers and libraries on Windows like you would on Linux.

That's a non-issue. Downloading, compiling and installing zlib on
Windows takes about 10 minutes, for both MinGW and MSVC. There are
pre-compiled packages around too.

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.

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

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.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: proposal to avoid zlib dependency.

Mueller-Roemer, Johannes Sebastian
In reply to this post by Dan Liew
It's half the way there. Configuring and compiling works, but linking fails, probably some definition mismatches...

But it can definitely be simplified, as due to the "REQUIRED" flag CMake will already fail if zlib isn't found, so no need for the

  if (ZLIB_FOUND)
    ...
  else()
    message(FATAL_ERROR "zlib was requested but it could not be found")
  endif()

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
[hidden email]  |  www.igd.fraunhofer.de


-----Original Message-----
From: Dan Liew [mailto:[hidden email]]
Sent: Wednesday, September 17, 2014 15:21
To: Mueller-Roemer, Johannes Sebastian
Cc: [hidden email]
Subject: Re: [LLVMdev] proposal to avoid zlib dependency.

On 17 September 2014 13:27, Mueller-Roemer, Johannes Sebastian <[hidden email]> wrote:
> Yes, this is incredibly annoying, so please avoid that. However I noticed that the current solution using CMake is broken, as I cannot enter my own ZLIB_ROOT, since no proper find_package is used.

I just had a go at hacking this so that we use find_package(ZLIB) if LLVM_ENABLE_ZLIB is used. Does the attached patch work correctly?

If so I could send to llvm-commits for review.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: proposal to avoid zlib dependency.

Dan Liew
On 17 September 2014 15:47, Mueller-Roemer, Johannes Sebastian
<[hidden email]> wrote:
> It's half the way there. Configuring and compiling works, but linking fails, probably some definition mismatches...

It configured, compiled and linked okay for me. Could you look into it?

>
> But it can definitely be simplified, as due to the "REQUIRED" flag CMake will already fail if zlib isn't found, so no need for the
>
>   if (ZLIB_FOUND)
>     ...
>   else()
>     message(FATAL_ERROR "zlib was requested but it could not be found")
>   endif()
>

Thanks. I'm aware that's what REQUIRED would do but I thought I'd try
to be "defensive" just in case someone later on thinks removing
"REQUIRED" is a good idea...

If you think its unnecessary clutter I'd happily remove it.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: proposal to avoid zlib dependency.

Mueller-Roemer, Johannes Sebastian
I'll have another look tomorrow.

IMO, it is unnecessary clutter. It will fail if ${ZLIB_LIBRARIES} or ${ZLIB_INCLUDE_DIRS} are used anyways as they will be set to NOTFOUND. Or we go back to a silent-fail solution:

find_package(ZLIB QUIET)
if (LLVM_ENABLE_ZLIB AND ZLIB_FOUND)
  set(HAVE_ZLIB_H 1)
  set(HAVE_LIBZ 1)
  list(APPEND CMAKE_REQUIRED_LIBRARIES ${ZLIB_LIBRARIES})
  list(APPEND CMAKE_REQUIRED_INCLUDES ${ZLIB_INCLUDE_DIRS})
else()
  set(HAVE_ZLIB_H 0)
  set(HAVE_LIBZ 0)
endif()

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
[hidden email]  |  www.igd.fraunhofer.de


-----Original Message-----
From: Dan Liew [mailto:[hidden email]]
Sent: Wednesday, September 17, 2014 17:26
To: Mueller-Roemer, Johannes Sebastian
Cc: [hidden email]
Subject: Re: [LLVMdev] proposal to avoid zlib dependency.

On 17 September 2014 15:47, Mueller-Roemer, Johannes Sebastian <[hidden email]> wrote:
> It's half the way there. Configuring and compiling works, but linking fails, probably some definition mismatches...

It configured, compiled and linked okay for me. Could you look into it?

>
> But it can definitely be simplified, as due to the "REQUIRED" flag
> CMake will already fail if zlib isn't found, so no need for the
>
>   if (ZLIB_FOUND)
>     ...
>   else()
>     message(FATAL_ERROR "zlib was requested but it could not be found")
>   endif()
>

Thanks. I'm aware that's what REQUIRED would do but I thought I'd try to be "defensive" just in case someone later on thinks removing "REQUIRED" is a good idea...

If you think its unnecessary clutter I'd happily remove it.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: proposal to avoid zlib dependency.

Dan Liew
On 17 September 2014 16:34, Mueller-Roemer, Johannes Sebastian
<[hidden email]> wrote:
> I'll have another look tomorrow.

Thanks.

> IMO, it is unnecessary clutter. It will fail if ${ZLIB_LIBRARIES} or ${ZLIB_INCLUDE_DIRS} are used anyways as they will be set to NOTFOUND. Or we go back to a silent-fail solution:

Fair enough. I've never been a big fan of silent failure. So perhaps
just this...

```
if (LLVM_ENABLE_ZLIB )
  find_package(ZLIB REQUIRED)
    set(HAVE_ZLIB_H 1)
    set(HAVE_LIBZ 1)
    list(APPEND CMAKE_REQUIRED_LIBRARIES ${ZLIB_LIBRARIES})
    list(APPEND CMAKE_REQUIRED_INCLUDES ${ZLIB_INCLUDE_DIRS})
else()
  set(HAVE_ZLIB_H 0)
  set(HAVE_LIBZ 0)
endif()
```

--
Dan Liew
PhD Student - Imperial College London
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: proposal to avoid zlib dependency.

Mueller-Roemer, Johannes Sebastian
Well, I just had a quick look again and there were two issues:

You added ${ZLIB_LIBRARIES} to CMAKE_REQUIRED_LIBRARIES not ${ZLIB_LIBRARY}
That was covered up under Linux/MacOSX by

if ( LLVM_ENABLE_ZLIB AND HAVE_LIBZ )
  set(system_libs ${system_libs} z)
endif()

in Support's CMakeLists.txt

I corrected the first point and removed the second. Now, HAVE_LIBZ and HAVE_ZLIB_H aren't used at all anymore so I removed those as well.

Patch attached.

PS: I wouldn't really consider CMAKE_REQUIRED_LIBRARIES/CMAKE_REQUIRED_INCLUDES a clean solution. target_include_directories and target_link_libraries offer much finer control.

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
[hidden email]  |  www.igd.fraunhofer.de


-----Original Message-----
From: Dan Liew [mailto:[hidden email]]
Sent: Wednesday, September 17, 2014 17:52
To: Mueller-Roemer, Johannes Sebastian
Cc: [hidden email]
Subject: Re: [LLVMdev] proposal to avoid zlib dependency.

On 17 September 2014 16:34, Mueller-Roemer, Johannes Sebastian <[hidden email]> wrote:
> I'll have another look tomorrow.

Thanks.

> IMO, it is unnecessary clutter. It will fail if ${ZLIB_LIBRARIES} or ${ZLIB_INCLUDE_DIRS} are used anyways as they will be set to NOTFOUND. Or we go back to a silent-fail solution:

Fair enough. I've never been a big fan of silent failure. So perhaps just this...

```
if (LLVM_ENABLE_ZLIB )
  find_package(ZLIB REQUIRED)
    set(HAVE_ZLIB_H 1)
    set(HAVE_LIBZ 1)
    list(APPEND CMAKE_REQUIRED_LIBRARIES ${ZLIB_LIBRARIES})
    list(APPEND CMAKE_REQUIRED_INCLUDES ${ZLIB_INCLUDE_DIRS})
else()
  set(HAVE_ZLIB_H 0)
  set(HAVE_LIBZ 0)
endif()
```

--
Dan Liew
PhD Student - Imperial College London

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

zlibfix.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: proposal to avoid zlib dependency.

Reid Kleckner-2
In reply to this post by Óscar Fuentes
On Wed, Sep 17, 2014 at 6:30 AM, Óscar Fuentes <[hidden email]> wrote:
Reid Kleckner <[hidden email]> writes:

> On Tue, Sep 16, 2014 at 7:47 PM, Óscar Fuentes <[hidden email]> wrote:
>
>> IIUC zlib availability is tested and the library used if present. Do you
>> mean that LLVM does not use zlib on Windows when the library is present?
>
>
> Sure, but if there aren't instructions for how to do it easily, then it's
> effectively unsupported. There isn't really a canonical way to "install"
> headers and libraries on Windows like you would on Linux.

That's a non-issue. Downloading, compiling and installing zlib on
Windows takes about 10 minutes, for both MinGW and MSVC. There are
pre-compiled packages around too.

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, and there isn't any documentation, which is just a hair shy of being unsupported. I agree, though, we can fix this. If GnuWin32 provides a usable zlib, that's great, we should document how to use it.

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

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.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
123