Re: [Boost-bugs] [Boost C++ Libraries] #9156: 1.54 broke NO_ZLIB=1 and NO_COMPRESSION=1

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #9156: 1.54 broke NO_ZLIB=1 and NO_COMPRESSION=1
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2015-04-29 22:41:15

#9156: 1.54 broke NO_ZLIB=1 and NO_COMPRESSION=1
  Reporter: Warren Togami | Owner: turkanis
  <wtogami@…> | Status: new
      Type: Bugs | Component: iostreams
 Milestone: Boost 1.55.0 | Severity: Regression
   Version: Boost 1.55.0 | Keywords: zlib iostreams
Resolution: | /zlib/zlib

Comment (by dd0t@…):

 The very same commit you identified seems to also break manual
 configuration of an external zlib in boost 1.58.0 (and earlier I guess) as
 described by the documentation
 Setting ZLIB_BINARY, ZLIB_INCLUDE and ZLIB_LIBPATH previously allowed to
 specify an externally compiled version of zlib with custom binary name.
 These options seem to no longer have any effect on the build configuration
 resulting in zlib not being found and disabled. Looking at the jamfile it
 seems like the previously used create-library rule had all the handling
 for that while the new ac.check-library probably isn't even aware of these
 parameters. Reverting the changes to the Jam files allows using the custom
 zlib version again.

 Unless the auto-detection can be made aware of those configuration options
 I don't think it is a viable replacement. For my use-case the whole
 application and dependencies (including boost) are statically linked so I
 have to prevent trying to link multiple versions of it when zlib is used
 elsewhere. Also this external zlib has a non-standard name (libzlib.a
 under linux instead of libz.a).

 In any case the documentation doesn't seem to properly reflect the current
 library behavior. Or maybe I'm just completely misunderstanding it which
 is always possible.

Ticket URL: <>
Boost C++ Libraries <>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:18 UTC