Hello Matthias.

I have been unable to build this package for the last 12 months:

Status: failed      gcc-8-cross_4_amd64-20180218T093520Z
Status: failed      gcc-8-cross_5_amd64-20180224T160324Z
Status: failed      gcc-8-cross_6_amd64-20180321T020921Z
Status: failed      gcc-8-cross_7_amd64-20180328T034559Z
Status: failed      gcc-8-cross_10_amd64-20180415T171623Z
Status: failed      gcc-8-cross_10_amd64-20180606T232216Z
Status: failed      gcc-8-cross_10_amd64-20180613T100719Z
Status: failed      gcc-8-cross_17_amd64-20180614T074203Z
Status: failed      gcc-8-cross_17_amd64-20180630T065556Z
Status: failed      gcc-8-cross_17_amd64-20180710T095437Z
Status: failed      gcc-8-cross_18_amd64-20180729T173009Z
Status: failed      gcc-8-cross_20_amd64-20180820T070711Z
Status: failed      gcc-8-cross_20_amd64-20180920T075713Z
Status: failed      gcc-8-cross_21_amd64-20180924T034119Z
Status: failed      gcc-8-cross_21_amd64-20181015T100546Z
Status: failed      gcc-8-cross_22_amd64-20181105T035318Z
Status: failed      gcc-8-cross_22_amd64-20181209T162522.011Z
Status: failed      gcc-8-cross_24_amd64-20181216T102727.612Z
Status: failed      gcc-8-cross_24_amd64-20190207T101228.086Z
Status: failed      gcc-8-cross_25_amd64-20190220T042620.026Z
Status: failed      gcc-8-cross_26_amd64-20190309T042203.371Z


This is how it fails:
--------------------------------------------------------------------------------
[...]
 debian/rules build-indep
gcc: 8.3.0-2 / 8.3.0-2cross1

old gcc version: 8.3.0-2 / 1

new gcc version: 8.3.0-2cross1
START stamp-dir/init-gcc
mkdir -p gcc
set -ex; \
cd gcc ; \
ln -sf /usr/src/gcc-8/gcc-8.3.0-dfsg.tar.xz gcc-8.3.0-dfsg.tar.xz ;\
cp -a  /usr/src/gcc-8/debian/ . ; \
if [ -n "$(grep -v '^\#' /<<PKGBUILDDIR>>/debian/patches/gcc-8/series)" ]; then \
  QUILT_PATCHES=/<<PKGBUILDDIR>>/debian/patches/gcc-8 quilt push --quiltrc /dev/null -a ; \

[... snipped ...]

#define HAVE_ICONV 1
#define ICONV_CONST
#define HAVE_GETIPINFO 1
#define HAVE_LINUX_FUTEX 1
#define _GLIBCXX_SYMVER_GNU 1
#define _GLIBCXX_SYMVER 1
#define HAVE_AS_SYMVER_DIRECTIVE 1
#define HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT 1
#define _GLIBCXX_X86_RDRAND 1
#define HAVE_UNISTD_H 1
#define HAVE_SYS_TIME_H 1
#define HAVE_SYS_RESOURCE_H 1
#define HAVE_LIMIT_DATA 1
#define HAVE_LIMIT_RSS 1
#define HAVE_LIMIT_VMEM 0
#define HAVE_LIMIT_AS 1
#define HAVE_LIMIT_FSIZE 1
#define _GLIBCXX_RES_LIMITS 1
#define HAVE_SETENV 1
#define _GTHREAD_USE_MUTEX_TIMEDLOCK 1
#define _GLIBCXX_HAS_GTHREADS 1
#define _GLIBCXX_USE_PTHREAD_RWLOCK_T 1
#define HAVE_FCNTL_H 1
#define HAVE_DIRENT_H 1
#define HAVE_SYS_STATVFS_H 1
#define HAVE_UTIME_H 1
#define HAVE_STRUCT_DIRENT_D_TYPE 1
#define _GLIBCXX_USE_REALPATH 1
#define _GLIBCXX_USE_UTIMENSAT 1
#define _GLIBCXX_USE_ST_MTIM 1
#define _GLIBCXX_USE_FCHMOD 1
#define _GLIBCXX_USE_FCHMODAT 1
#define _GLIBCXX_USE_SENDFILE 1
#define _GLIBCXX_MANGLE_SIZE_T m
#define HAVE_EXCEPTION_PTR_SINCE_GCC46 1

configure: exit 0
LOGFILE END /<<PKGBUILDDIR>>/gcc/build/x86_64-linux-gnu/libstdc++-v3/config.log
make[2]: *** [debian/rules2:1221: stamps/05-build-stamp] Error 1
make[2]: Leaving directory '/<<PKGBUILDDIR>>/gcc'
make[1]: *** [debian/rules:44: build-indep] Error 2
make[1]: Leaving directory '/<<PKGBUILDDIR>>/gcc'
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit status 2
make: *** [debian/rules:397: stamp-dir/build-gcc.amd64] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit status 2
--------------------------------------------------------------------------------

This is just how the build ends and probably meaningless, so I've put
all my build logs here:

https://people.debian.org/~sanvila/build-logs/gcc-8-cross/

The only unusual thing is that I'm using a single-CPU virtual machine
for the build, not a desktop computer, but I fail to see why that
would make any difference, as the only processor-related thing
I found is this in debian/rules:

NJOBS =
# Support parallel=<n> in DEB_BUILD_OPTIONS (see #209008)
ifneq (,$(filter parallel=%,$(subst $(,), ,$(DEB_BUILD_OPTIONS))))
  NJOBS := -j $(subst parallel=,,$(filter parallel=%,$(subst $(,),$(space),$(DEB_BUILD_OPTIONS))))
endif

which I believe is pretty standard and should not affect the end result.

So: What could be the reason for the failure? A bug in one of the Makefiles?

Thanks.

I've looked at the log and found a more useful bit:

| ../../gnatbind -I- -nostdinc -I/<<PKGBUILDDIR>>/gcc/build/x86_64-linux-gnu/libgnatvsn -I/<<PKGBUILDDIR>>/gcc/build/gcc/ada/rts -I. -I/<<PKGBUILDDIR>>/gcc/src/gcc/ada -o b_gnatm.adb gnatmake.ali
| /bin/bash: ../../gnatbind: No such file or directory
| make[6]: *** [../gcc-interface/Makefile:2707: b_gnatm.adb] Error 127
| make[6]: Leaving directory '/<<PKGBUILDDIR>>/gcc/build/gcc/ada/tools'
| make[5]: *** [Makefile:205: gnattools-native] Error 2
| make[5]: Leaving directory '/<<PKGBUILDDIR>>/gcc/build/gnattools'
| make[4]: *** [Makefile:9602: all-gnattools] Error 2
| make[4]: Leaving directory '/<<PKGBUILDDIR>>/gcc/build'
| make[3]: *** [Makefile:923: all] Error 2
| make[3]: Leaving directory '/<<PKGBUILDDIR>>/gcc/build'

This could be a missing dependency of some sorts. Matthias usually does
source-only uploads and the package builds fine on the buildds though.
Santiago has been doing a non-parallel indep-only build here. Possibly
the parallel build gets the dependency right by chance?

Helmut

Control: severity -1 important
[...]

I have no clue, I have never seen that before, and it seems to work fine on the
buildds, and in the cross-toolchain-base* package's autopkg test.  Starting here
a build with -j1 to see if it's reproducible.

Is this seen with gcc-7-cross and gcc-9-cross as well?

It happened to me with the (now removed) gcc-7-cross as well, yes.
In case it helps, these are the logs I had in my last backup:

https://people.debian.org/~sanvila/build-logs/gcc-7-cross/

(Never tried gcc-9-cross yet because my usual target is testing and
sometimes sid).

Thanks a lot.

a gcc-9 build with -j1 succeeds.  I'm not spending more time on this.

Matthias

I'm confused. What do you mean by "a gcc-9 build"?

Did you try to build gcc-9-cross instead of gcc-8-cross, which is the
package in the bug report?

Or you mean that you tried to build gcc-8-cross using gcc-9 as the C compiler?

Thanks.

gcc-9-cross, yes.

Yes, it happened with gcc-7-cross:

https://people.debian.org/~sanvila/build-logs/gcc-7-cross/

and it also happens with gcc-9-cross:

https://people.debian.org/~sanvila/build-logs/gcc-9-cross/

Thanks.

I'm sorry that -j1 did not work for you, but this seems to fail every
time if you try in a single-CPU machine.

You can see it fail in real time here:

https://jenkins-1.reliable-builds.org/job/gcc-8-cross/

If trying in a single-CPU machine is a burden for you, please contact
me privately and I will gladly provide full access to a single-CPU
machine. (Same offer for Helmut in case he wants to confirm that this
bug is indeed real and not the result of a misconfiguration on my side).

Thanks.

Dear submitter,

as the package gcc-8-cross has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/954831

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)

reopen 924325
retitle 924325 gcc-8-cross: FTBFS because of Makefile bug: ../../gnatbind: No such file or directory
notfixed 924325 33+rm
severity 924325 serious
thanks

I'm reopening this bug because packages in stable *must* build in stable.

While it's true that this bug has not happened in the buildds so far,
I have been able to reproduce it every time during the last months/years:

https://jenkins-1.reliable-builds.org/job/gcc-8-cross/

and the end user is *not* to blame for this, as it is a Makefile bug.

(This is arguably a GPL violation, as the GPL mandates that packages
must include a working Makefile, which is not the case here).

If you need a machine on which this happens all the time, please contact
me privately and I will gladly provide a virtual machine for that.

Thanks.

Downgrading, building sequentially is nice to have, but not a must.  And
as you write, your fix just papers over a dependency issue.  Please
could you address this upstream, if it's really important for you?