Your message dated Mon, 21 Nov 2016 00:33:17 +0100
with message-id <6f5e8018-4a94-fb0a-8bd6-0b871eb38...@debian.org>
and subject line Re: Bug#845143: cross-toolchain-base: FTBFS in stage1 gcc:
libiberty uses libc headers
has caused the Debian Bug report #845143,
regarding cross-toolchain-base: FTBFS in stage1 gcc: libiberty uses libc headers
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
845143: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845143
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: cross-toolchain-base
Version: 13
Severity: serious
User: helm...@debian.org
Usertags: rebootstrap
Hi Matthias,
Since a few gcc-6 uploads, cross-toolchain-base FTBFS. I don't know
exactly which version made it break, but 6.2.1-4 is known to be broken
and 6.2.0-13 is known to not have this issue (which is different from
#844866). The symptom is:
| config.status: creating config.h
| config.status: config.h is unchanged
| config.status: executing default commands
| if [ x"" != x ]; then \
| /<<PKGBUILDDIR>>/gcc/build/./gcc/xgcc -B/<<PKGBUILDDIR>>/gcc/build/./gcc/
-B/usr/s390x-linux-gnu/bin/ -B/usr/s390x-linux-gnu/lib/ -isystem
/usr/s390x-linux-gnu/include -isystem /usr/s390x-linux-gnu/sys-include -isystem
/<<PKGBUILDDIR>>/gcc/build/sys-include
--sysroot=/<<PKGBUILDDIR>>/debian/tmp.s390x -c -DHAVE_CONFIG_H -g -O2 -I.
-I../../../src/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic -D_GNU_SOURCE ../../../src/libiberty/regex.c -o
pic/regex.o; \
| else true; fi
| if [ x"" != x ]; then \
| /<<PKGBUILDDIR>>/gcc/build/./gcc/xgcc -B/<<PKGBUILDDIR>>/gcc/build/./gcc/
-B/usr/s390x-linux-gnu/bin/ -B/usr/s390x-linux-gnu/lib/ -isystem
/usr/s390x-linux-gnu/include -isystem /usr/s390x-linux-gnu/sys-include -isystem
/<<PKGBUILDDIR>>/gcc/build/sys-include
--sysroot=/<<PKGBUILDDIR>>/debian/tmp.s390x -c -DHAVE_CONFIG_H -g -O2 -I.
-I../../../src/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic -D_GNU_SOURCE ../../../src/libiberty/regex.c
-o noasan/regex.o; \
| else true; fi
| /<<PKGBUILDDIR>>/gcc/build/./gcc/xgcc -B/<<PKGBUILDDIR>>/gcc/build/./gcc/
-B/usr/s390x-linux-gnu/bin/ -B/usr/s390x-linux-gnu/lib/ -isystem
/usr/s390x-linux-gnu/include -isystem /usr/s390x-linux-gnu/sys-include -isystem
/<<PKGBUILDDIR>>/gcc/build/sys-include
--sysroot=/<<PKGBUILDDIR>>/debian/tmp.s390x -c -DHAVE_CONFIG_H -g -O2 -I.
-I../../../src/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic -D_GNU_SOURCE ../../../src/libiberty/regex.c -o
regex.o
| ../../../src/libiberty/regex.c:52:25: fatal error: sys/types.h: No such file
or directory
| # include <sys/types.h>
| ^
| compilation terminated.
| Makefile:1166: recipe for target 'regex.o' failed
| make[5]: *** [regex.o] Error 1
| make[5]: Leaving directory
'/<<PKGBUILDDIR>>/gcc/build/s390x-linux-gnu/libiberty'
| Makefile:11866: recipe for target 'all-target-libiberty' failed
| make[4]: *** [all-target-libiberty] Error 2
| make[4]: Leaving directory '/<<PKGBUILDDIR>>/gcc/build'
| Makefile:861: recipe for target 'all' failed
| make[3]: *** [all] Error 2
| make[3]: Leaving directory '/<<PKGBUILDDIR>>/gcc/build'
It occurs during the stage1 gcc build while building libiberty. The
issue is independent of the target architecture. s390x just happens to
be the first one tried by cross-toolchain-base. We see that regex.c
includes libc headers, but a stage1 build should not be using libc
headers. I looked into the recent gcc-6 packaging commits and couldn't
identify an obvious cause. I also looked into recently successful cross
compiler builds an it seems that formerly libiberty was only built for
the host architecture and not for the target architecture in stage1.
I am Ccing d-cross@l.d.o to gain more eyeballs for the issue. Any ideas?
Helmut
--- End Message ---
--- Begin Message ---
Version: 14
--- End Message ---
