Building media-video/gpac-0.4.5-r1 (with zlib-1.2.5-r1) fails during compile with x86_64-pc-linux-gnu-gcc -O2 -pipe -march=k8 -fno-strict-aliasing -I/var/tmp/portage/media-video/gpac-0.4.5-r1/work/gpac/include -I../ -DGPAC_HAVE_CONFIG_H -c -o utils/xml_parser.o utils/xml_parser.c In file included from utils/xml_parser.c:30: /usr/include/zlib.h:1575:46: error: operator '&&' has no right operand make[1]: *** [utils/xml_parser.o] gpac-0.4.5-r1 did build on my machine before. gpack does build and install with zlib-1.2.5 Reproducible: Always Steps to Reproduce: 1. emerge zlib-1.2.5-r1 2. emerge gpac 3. Actual Results: gpac fails to compile Expected Results: gpac builds and installs My temporary solution is to install zlib-1.2.5 emerge --oneshot gpac upgrade zlib to zlib-1.2.5-r1
Diego, looks like the patch in -r1 isn't... exactly working as it's supposed.
Mind if I ask which GCC version, and the content of the generated config.h?
I had the same problem, gcc is 4.4.3-r2, zlib was 1.2.5-r1, but downgrading to zlib 1.2.5 solved it.
Can somebody give me that file? I don't care if downgrades solve it, the downgrade breaks _more_ than it solves. We just need to fix this for good.
/var/tmp/portage/media-video/gpac-0.4.5-r1/work/gpac/config.h /* Automatically generated by configure */ #ifndef GF_CONFIG_H #define GF_CONFIG_H #define GPAC_CONFIG_LINUX #define GPAC_HAS_JPEG #define GPAC_HAS_PNG #define GPAC_HAS_SSL #define GPAC_HAS_IPV6 #endif And with gcc-4.5.0.
Instead, I would change _LARGEFILE64_SOURCE with defined(_LARGEFILE64_SOURCE) in /usr/include/zlib.h line 1574 #if !defined(ZLIB_INTERNAL) && _FILE_OFFSET_BITS-0 == 64 && \ _LFS64_LARGEFILE-0 && _LARGEFILE64_SOURCE becomes #if !defined(ZLIB_INTERNAL) && _FILE_OFFSET_BITS-0 == 64 && \ _LFS64_LARGEFILE-0 && defined(_LARGEFILE64_SOURCE) I didn't check further...
Different semantics: # if FOO will fail if FOO is undefined or defined to 0 # if defined(FOO) will fail if FOO is undefined, but will proceed if it's defined to 0.
*** Bug 317723 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > Different semantics: > > # if FOO > > will fail if FOO is undefined or defined to 0 why not using # if FOO-0 for this, just like in the other parts of zlib.h ?
Mostly because I was hoping to test that sooner… Alexis can you confirm that fixes it? If so, please feel free to bump to -r2 doing just that…
I'm just blind guessing from an x86_64 here :) anyway, considering this in zconf.h: /* a little trick to accommodate both "#define _LARGEFILE64_SOURCE" and * "#define _LARGEFILE64_SOURCE 1" as requesting 64-bit operations, (even * though the former does not conform to the LFS document), but considering * both "#undef _LARGEFILE64_SOURCE" and "#define _LARGEFILE64_SOURCE 0" as * equivalently requesting no 64-bit operations */ #if -_LARGEFILE64_SOURCE - -1 == 1 # undef _LARGEFILE64_SOURCE #endif # if and #if defined() should be equivalent here.
(In reply to comment #11) > I'm just blind guessing from an x86_64 here :) not that blind actually, it fails here too
well, both luatex and gpac worked fine with the new 1.2.5-r2.
The same goes for dovecot (which hit on the tinderbox).
You guys are terrific! zlib-1.2.5-r2 fixed my gpac and luatex here. gcc-4.4.3 glibc-2.11.1-r0 vanilla-sources-2.6.33.2 on a Pentium 3 Mobile system. Thanks!
Closing this as fixed by zlib-1.2.5-r2.
