http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45174
John Tytgat <John.Tytgat at aaug dot net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |John.Tytgat at aaug dot net
--- Comment #26 from John Tytgat <John.Tytgat at aaug dot net> 2011-01-18
01:15:57 UTC ---
I'm seeing the same problem with gcc 4.6 trunk (r168937) for building a cross
compiler with target arm-unknown-eabi configured with newlib in tree. The
crucial bit is --enable-multilib, without this option the problem is not
reproducible.
It looks like the --enable-multilib enables building the multilibs of the host
(instead of the target) for zlib. In my case the host is (on Ubuntu 10.04):
$ gcc -dumpmachine
x86_64-linux-gnu
$ gcc -print-multi-lib
.;
32;@m32
I've attached my buildlog and the full content of gcc builddir subdirectories
'zlib' and '32/zlib' (the latter not present when --enable-multilib is
omitted).
Also like the original bug reporter is saying: I can avoid this problem by
specifying --with-system-zlib.
