Boost C++ Libraries: Ticket #1967: bjam bug? iostreams + zlib won't build for VC8 or MinGW with small hack to Jamfile.v2

attachment set

brian.pratt@… — Thu, 29 May 2008 15:48:43 GMT

attachment → Jamfile.v2

hacked iostreams Jamfile.v2 that allows zlib use in VC8 and MinGW

component changed; owner set

Marshall Clow — Tue, 03 Jun 2008 14:06:44 GMT

owner set to Vladimir Prus
component None → Building Boost

Vladimir Prus — Tue, 03 Jun 2008 14:52:04 GMT

Can you provide a little bit more explanations? On NT, we already set NO_$(LIB) to 1 a few lines earlier, unless you provide the path to the zlib source. So, what exactly are you doing, how it works, and how you want it to work.

Also, please provide changes as unified diff against SVN HEAD, if possible.

brian.pratt@… — Tue, 03 Jun 2008 18:56:35 GMT

I notice a typo in the bug description, I meant to say "without small hack", of course. Oops.

Near as I can tell the problem is that when NO_ZLIB is defined to 0 it still triggers the logic, as if it's an ifdef instead of an if, if you see what I mean.

Here's my change as a unified diff against trunk as requested:

--- Jamfile.orig Tue Jun 3 11:52:46 2008 +++ Jamfile.v2 Thu May 29 07:58:30 2008 @@ -55,7 +55,8 @@

modules.poke : NO_$(LIB) : 1 ;

}

if $(NO_COMPRESSION)

$(NO_$(LIB))

+ # bpratt added the = 1 tests here to get zlib working in MinGW and VC8

+ if $(NO_COMPRESSION) = 1

$(NO_$(LIB)) = 1

{

if $(debug) {

@@ -141,7 +142,6 @@

René Rivera — Tue, 03 Jun 2008 19:07:21 GMT

Replying to brian.pratt@insilicos.com:

Near as I can tell the problem is that when NO_ZLIB is defined to 0 it still triggers the logic, as if it's an ifdef instead of an if, if you see what I mean.

AFAICT, this is intentional in the iostreams Jamfile. And it doesn't set them to "0" anywhere I can see. How are you seeing it being set to "0"?

brian.pratt@… — Tue, 03 Jun 2008 19:57:14 GMT

Since NO_ZLIB defaults to 1 for VC8 and MinGW, it's necessary to set it to 0 at the bjam commandline (-sNO_ZLIB=0). My experience, though, was that this didn't work, and that the test as written seemed to act more as an "ifdef NO_ZLIB". If the test is rewritten to check explicitly for value "1" it acts as required and the zlib build is enabled. It's as if bjam has forgotten the difference between a boolean (zero vs everything else) and an ifdef (undefined vs everything else).

Vladimir Prus — Wed, 04 Jun 2008 04:48:58 GMT

By my reading of the code, NO_ZLIB will be set to 1, if you're on Windows, and have not set both ZLIB_SOURCE and ZLIB_INCLUDE. If you set NO_ZLIB=0 on command line and do not set ZLIB_SOURCE and ZLIB_INCLUDE, zlib won't be used anyway. And if you do set ZLIB_SOURCE and ZLIB_INCLUDE, zlib should be used without any other option. So, back to original question -- what exactly are you doing (exact command line), and what effect you see?

brian.pratt@… — Wed, 04 Jun 2008 14:34:30 GMT

bjam -toolset=msvc "-sNO_ZLIB=0" -sZLIB_SOURCE="/zlib123-dll" --build-type=complete --without-python --without-mpi stage

I tried various permutations of ZLIB_SOURCE, ZLIB_INCLUDE etc (docs are exceedingly murky on this), this commandline together with the patch is the one that results in zlib being enabled. Everything else gave the default no zlib behavior.

alessandro_vergani — Wed, 10 Sep 2008 08:05:04 GMT

The problem happens also with VC9. I think it is a problem with bjam because if I place in the jamfile.v2 a simple test like:

if 0 {

ECHO "Error" ;

}

the test always succeeds and the error string is diplayed.

Explicitly comparing for equality with 1 solves the problem.

status changed; resolution set

Vladimir Prus — Sat, 04 Apr 2009 12:45:00 GMT

status new → closed
resolution → fixed

(In [52168]) Check if value of NO_COMPRESSION/NO_ZLIB is 0 or 1.

Originally, only presence of these variables was checked. Unfortunately, iostreams documentation said, incorrectly, that NO_ZLIB and NO_BZIP2 default to 1 on Windows, which caused some users to pass NO_ZLIB=0 explicitly, together with other variables,thereby still disabling zlib.

This match makes Jamfile forgiving of this error.

Fixes #1967.