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.

Hello.

Please consider the attached patch (suggested by Sergei Trofimovich).

Explanation: In a failed build log, we can see this:

for tool in gnatbind gnatchop gnat gnatkr gnatlink gnatls gnatmake gnatname gnatprep gnatclean ; do \
   if [ -f $tool ] ; \
   then \
     mv $tool $tool-cross; \
   fi; \
done

and later:

/bin/bash: line 1: ../../gnatbind: No such file or directory
make[6]: *** [../gcc-interface/Makefile:918: b_gnatm.adb] Error 127
make[6]: Leaving directory '/<<PKGBUILDDIR>>/gcc/build/gcc/ada/tools'
make[5]: *** [Makefile:210: gnattools-native] Error 2
make[5]: Leaving directory '/<<PKGBUILDDIR>>/gcc/build/gnattools'
make[4]: *** [Makefile:10700: all-gnattools] Error 2
make[4]: Leaving directory '/<<PKGBUILDDIR>>/gcc/build'
make[3]: *** [Makefile:1064: all] Error 2
make[3]: Leaving directory '/<<PKGBUILDDIR>>/gcc/build'

So, gnatbind does not exist because it has been renamed prematurely.

As pointed out by Helmut Grohne in #924325, there seems to be a missing
dependency somewhere, but as far as such missing dependency is not spotted
and fixed, the attached patch (which just does "cp -p" instead of "mv")
will be a lot better than nothing.

Note: The proposed patch is against gcc-14. I have actually tested the patch
and it works (using the generated "gcc-14-source" package to build gcc-14-cross).
The same patch should apply to the other gcc-nn packages.

To reproduce the build failure, please try GRUB_CMDLINE_LINUX="nr_cpus=1".
The failure rate seeems to be 100% that way. Failed build logs
will be like this:

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

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?

[ Matthias, please always Cc me on the bugs I report if you talk to me
in your replies ]

[ Trimming Cc list to just gcc-14-cross for simplicity. Still Cc to
ADA people, I'd love to hear from them ].

What do you mean by "sequentially"? Whether the build happens
"sequentially" or not will depend on what you do in debian/rules.

For example, in gcc-8-cross version 27 you already did something
like this:

   ifeq ($(JOBS),1)
     JOBS := 2
   endif

so that the build is never "sequential", and it allowed everybody
to build the package (unfortunately, I think the package was
removed from unstable before the fix became part of a stable release).

In either case, Debian Policy 4.2 says that packages *must*
build from source when build-dependencies are installed,
so yes, this is a must, not just a "nice thing to have".

We have seen calls to the TC for a lot less than this,
and we have seen NMUs from reproducible-builds people
to make packages reproducible, which is just a "should".

I'm not reporting that the package has makefile bugs in
a "general sense". There are hundreds of such bugs:

https://people.debian.org/~sanvila/make-shuffle/

but that's not the issue here.

I'm reporting that the package fails in a very specific way,
and the proposed patch makes such specific mode of failure not to
happen at all.

It was you who said "patches welcome" a long time ago
regarding this bug. Now I expect you to honor your word.

I could report this upstream, but there are several problems
with that:

A) This is a complex package and I don't really know if
you are using those makefiles to create cross compilers
in the way they were designed to be used. Only you know that.

B) Reporting a GCC bug upstream requires a minimal case.
I don't have a minimal case for this. It's the whole package
what's wrong. This is a Debian bug.

C) I report many FTBFS bugs, each of them has a different
upstream bug tracker. If I had to report them upstream,
I would have to open an account in each of those bug tracking
systems. This definitely does not scale.

D) I wonder how you would feel if anybody suggested that
you had to be the one to forward *any* of these bugs upstream:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-gcc@lists.debian.org;tag=ftbfs-gcc-15



You can make the failure not to happen in several different ways.
Just choose the one which makes you more happy. I think it would be
acceptable if you implement the workaround in gcc-8-cross at the same
time you ask upstream for a better fix. I don't mind that the fix is not
the better fix, but I do mind if you deliberately choose to ignore a must
directive in Policy when there is a patch on the table.

Thanks.

Do you still refuse to fix it on the basis that it's "not a bug
just a nice thing to have"? (You have not explained yet why Policy 4.2,
a must directive, does not apply here).

Thanks.

this is not a fix, you are working around it. If you want to get this
solved, please send a patch upstream, explaining your issue, and
together with a properly tested fix.