Bug#844855: gcc-5: FTBFS: conftest.c:136: undefined reference to `setproctitle'
On 03.12.2016 11:58, Santiago Vila wrote: > Sorry, did not see the part about internal compiler error in the buld log > itself. Still amazed that you can be so sure that it's hardware related when > he is using virtual machines. The message reads: The bug is not reproducible, so it is likely a hardware or OS problem. The driver retries the build up to three times, and apparently succeeds (succeeding means here failing to reproduce the ICE). But maybe the build log analysis could be improved: - search for the 'unfinished' output from make, and add the lines before that message to the bug reports. - explicitly look for the gcc ICE messages
Bug#844855: gcc-5: FTBFS: conftest.c:136: undefined reference to `setproctitle'
Sorry, did not see the part about internal compiler error in the buld log itself. Still amazed that you can be so sure that it's hardware related when he is using virtual machines. Thanks. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#844855: gcc-5: FTBFS: conftest.c:136: undefined reference to `setproctitle'
On 03.12.2016 10:41, Santiago Vila wrote:
> On Sat, Dec 03, 2016 at 10:08:33AM +0100, Lucas Nussbaum wrote:
>
>> Just for the record: I can still reproduce this failure.
>
> Then, IMHO, you should reopen the bug.
>
>
> I bet it's a Makefile bug related to parallel building, because my
> autobuilders are single-CPU and I also have this in my .sbuilrc file:
>
> $ENV{'DEB_BUILD_OPTIONS'} = 'parallel=1';
>
> and gcc-5 builds ok for me.
>
> Can you try putting that in .sbuildrc and see if the problem disappear?
>
> That would confirm that it's a Makefile bug, I think.
I don't think so.
https://buildd.debian.org/status/package.php?p=gcc-5
again doesn't show any build failures.
Santiago, it's really annoying that you insist on a Makefile issue when no
Makefile is involved. It's an an unreproducible GCC ICE:
../../src/gcc/reload1.c: In function 'void choose_reload_regs(insn_chain*)':
../../src/gcc/reload1.c:7185:1: internal compiler error: Segmentation fault
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
Makefile:1077: recipe for target 'reload1.o' failed
make[5]: *** [reload1.o] Error 1
Bug#844855: gcc-5: FTBFS: conftest.c:136: undefined reference to `setproctitle'
On Sat, Dec 03, 2016 at 10:08:33AM +0100, Lucas Nussbaum wrote:
> Just for the record: I can still reproduce this failure.
Then, IMHO, you should reopen the bug.
I bet it's a Makefile bug related to parallel building, because my
autobuilders are single-CPU and I also have this in my .sbuilrc file:
$ENV{'DEB_BUILD_OPTIONS'} = 'parallel=1';
and gcc-5 builds ok for me.
Can you try putting that in .sbuildrc and see if the problem disappear?
That would confirm that it's a Makefile bug, I think.
Thanks.
Bug#844855: gcc-5: FTBFS: conftest.c:136: undefined reference to `setproctitle'
Hi, Just for the record: I can still reproduce this failure. Lucas
Bug#844855: gcc-5: FTBFS: conftest.c:136: undefined reference to `setproctitle'
On Wed, Nov 23, 2016 at 12:26:18AM +0100, Matthias Klose wrote: > > What would be the right package for a bug in one of GCC Makefiles, then? > > > > What if Lucas was able to reproduce this in two different machines and > > the failure and the error message was the same? Would you discard > > "filesystem corruption" as the "most likely reason" in such case? > > > > [ Or maybe you are claiming that GCC Makefiles are 100% bug-free and > > absolutely perfect and any evidence in contrary *must* be an error? > > I really hope that's not what you meant here. ] > > what have Makefile errors to do with GCC ICEs? The gcc driver starts the > compiler again and tries to reproduce it. Nothing to do with Makefiles. A buggy Makefile was just an example of bug which does not always happen. Just because a bug does not always happen does not mean it is not a bug. But you closed this one as if the error that was reported could only happen in a parallel universe, not in this one. Is there any particular reason why GCC may not have a bug which does not always happen? Thanks.
Bug#844855: gcc-5: FTBFS: conftest.c:136: undefined reference to `setproctitle'
On 21.11.2016 13:09, Santiago Vila wrote: > On Sat, 19 Nov 2016, Matthias Klose wrote: > >>> It's unlikely a hardware problem because the build was made in a >>> virtual machine and the build was tried twice. This is written >>> in the bug report itself. >>> >>> This is a lot more likely to be a bug which happens randomly, >>> for example, a bug in the Makefile. >>> >>> Such bugs *do* exist, just see >>> >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841096 >>> >>> for a very simple example. >>> >>> >>> In this case, there is absolutely zero evidence that it's a hardware >>> problem and not a bug which happens randomly. >>> >>> Do you always close bugs which happen randomly just because you can't >>> reproduce them yourself, or can you acknowledge the fact that not all >>> packages either always build or always fail? >>> >>> (I can give a lot more examples of packages which fail to build >>> randomly if you are interested). >> >> it might not be "hardware" problem, but with all this "virtual overhead" a >> corruption with some file system or something else. Yes, I intend to close >> such >> bug reports, > > It's completely ok to close a report which happens because of hardware > problems. However, that's not the kind of randomness I was talking > about. > > I refer, for example, to randomness which happens when some Makefile > expect the output of "find" to be in a certain order. > > [ Please read the link I posted before ] > > There is no canonical order for the output of "find", so different > filesystem ordering does not mean the system is misconfigured or that > there is corruption in the filesystem. > >> because GCC itself retries to build these files, and apparently it >> succeeded to build it (or else you wouldn't see this message). That might >> be a >> real bug, but then GCC is the wrong package to file a bug report for. > > What would be the right package for a bug in one of GCC Makefiles, then? > > What if Lucas was able to reproduce this in two different machines and > the failure and the error message was the same? Would you discard > "filesystem corruption" as the "most likely reason" in such case? > > [ Or maybe you are claiming that GCC Makefiles are 100% bug-free and > absolutely perfect and any evidence in contrary *must* be an error? > I really hope that's not what you meant here. ] what have Makefile errors to do with GCC ICEs? The gcc driver starts the compiler again and tries to reproduce it. Nothing to do with Makefiles.
Bug#844855: gcc-5: FTBFS: conftest.c:136: undefined reference to `setproctitle'
On Sat, 19 Nov 2016, Matthias Klose wrote: > > It's unlikely a hardware problem because the build was made in a > > virtual machine and the build was tried twice. This is written > > in the bug report itself. > > > > This is a lot more likely to be a bug which happens randomly, > > for example, a bug in the Makefile. > > > > Such bugs *do* exist, just see > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841096 > > > > for a very simple example. > > > > > > In this case, there is absolutely zero evidence that it's a hardware > > problem and not a bug which happens randomly. > > > > Do you always close bugs which happen randomly just because you can't > > reproduce them yourself, or can you acknowledge the fact that not all > > packages either always build or always fail? > > > > (I can give a lot more examples of packages which fail to build > > randomly if you are interested). > > it might not be "hardware" problem, but with all this "virtual overhead" a > corruption with some file system or something else. Yes, I intend to close > such > bug reports, It's completely ok to close a report which happens because of hardware problems. However, that's not the kind of randomness I was talking about. I refer, for example, to randomness which happens when some Makefile expect the output of "find" to be in a certain order. [ Please read the link I posted before ] There is no canonical order for the output of "find", so different filesystem ordering does not mean the system is misconfigured or that there is corruption in the filesystem. > because GCC itself retries to build these files, and apparently it > succeeded to build it (or else you wouldn't see this message). That might be > a > real bug, but then GCC is the wrong package to file a bug report for. What would be the right package for a bug in one of GCC Makefiles, then? What if Lucas was able to reproduce this in two different machines and the failure and the error message was the same? Would you discard "filesystem corruption" as the "most likely reason" in such case? [ Or maybe you are claiming that GCC Makefiles are 100% bug-free and absolutely perfect and any evidence in contrary *must* be an error? I really hope that's not what you meant here. ] Thanks.
Bug#844855: gcc-5: FTBFS: conftest.c:136: undefined reference to `setproctitle'
On 19.11.2016 22:54, Santiago Vila wrote: > On Sat, 19 Nov 2016, Matthias Klose wrote: > >> On 19.11.2016 07:40, Lucas Nussbaum wrote: >>> Source: gcc-5 >>> Version: 5.4.1-3 >>> Severity: serious >>> Tags: stretch sid >>> User: debian...@lists.debian.org >>> Usertags: qa-ftbfs-20161118 qa-ftbfs >>> Justification: FTBFS on amd64 >>> >>> Hi, >>> >>> During a rebuild of all packages in sid, your package failed to build on >>> amd64. >>> >>> Relevant part (hopefully): >> >> no, not the relevant part (you get it by searching for "unfinished": >> >> The bug is not reproducible, so it is likely a hardware or OS problem. >> Makefile:1077: recipe for target 'reload1.o' failed >> make[5]: *** [reload1.o] Error 1 >> make[5]: *** Waiting for unfinished jobs >> >> closing, that's an issue with the environment. > > It's unlikely a hardware problem because the build was made in a > virtual machine and the build was tried twice. This is written > in the bug report itself. > > This is a lot more likely to be a bug which happens randomly, > for example, a bug in the Makefile. > > Such bugs *do* exist, just see > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841096 > > for a very simple example. > > > In this case, there is absolutely zero evidence that it's a hardware > problem and not a bug which happens randomly. > > Do you always close bugs which happen randomly just because you can't > reproduce them yourself, or can you acknowledge the fact that not all > packages either always build or always fail? > > (I can give a lot more examples of packages which fail to build > randomly if you are interested). it might not be "hardware" problem, but with all this "virtual overhead" a corruption with some file system or something else. Yes, I intend to close such bug reports, because GCC itself retries to build these files, and apparently it succeeded to build it (or else you wouldn't see this message). That might be a real bug, but then GCC is the wrong package to file a bug report for. Matthias
Bug#844855: gcc-5: FTBFS: conftest.c:136: undefined reference to `setproctitle'
On Sat, 19 Nov 2016, Matthias Klose wrote: > On 19.11.2016 07:40, Lucas Nussbaum wrote: > > Source: gcc-5 > > Version: 5.4.1-3 > > Severity: serious > > Tags: stretch sid > > User: debian...@lists.debian.org > > Usertags: qa-ftbfs-20161118 qa-ftbfs > > Justification: FTBFS on amd64 > > > > Hi, > > > > During a rebuild of all packages in sid, your package failed to build on > > amd64. > > > > Relevant part (hopefully): > > no, not the relevant part (you get it by searching for "unfinished": > > The bug is not reproducible, so it is likely a hardware or OS problem. > Makefile:1077: recipe for target 'reload1.o' failed > make[5]: *** [reload1.o] Error 1 > make[5]: *** Waiting for unfinished jobs > > closing, that's an issue with the environment. It's unlikely a hardware problem because the build was made in a virtual machine and the build was tried twice. This is written in the bug report itself. This is a lot more likely to be a bug which happens randomly, for example, a bug in the Makefile. Such bugs *do* exist, just see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841096 for a very simple example. In this case, there is absolutely zero evidence that it's a hardware problem and not a bug which happens randomly. Do you always close bugs which happen randomly just because you can't reproduce them yourself, or can you acknowledge the fact that not all packages either always build or always fail? (I can give a lot more examples of packages which fail to build randomly if you are interested). Thanks.
Bug#844855: gcc-5: FTBFS: conftest.c:136: undefined reference to `setproctitle'
Source: gcc-5 Version: 5.4.1-3 Severity: serious Tags: stretch sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20161118 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > /tmp/ccAZve4U.o: In function `main': > /<>/build/libiberty/conftest.c:129: warning: the use of `tmpnam' > is dangerous, better use `mkstemp' > configure:6142: $? = 0 > configure:6142: result: yes > configure:6142: checking for vasprintf > configure:6142: /<>/build/./prev-gcc/xgcc > -B/<>/build/./prev-gcc/ -B/usr/x86_64-linux-gnu/bin/ > -B/usr/x86_64-linux-gnu/bin/ -B/usr/x86_64-linux-gnu/lib/ -isystem > /usr/x86_64-linux-gnu/include -isystem /usr/x86_64-linux-gnu/sys-include > -isystem /<>/build/sys-include-o conftest -g -O2 > -fprofile-use -static-libstdc++ -static-libgcc -Wl,-z,relro conftest.c >&5 > configure:6142: $? = 0 > configure:6142: result: yes > configure:6142: checking for vfprintf > configure:6142: /<>/build/./prev-gcc/xgcc > -B/<>/build/./prev-gcc/ -B/usr/x86_64-linux-gnu/bin/ > -B/usr/x86_64-linux-gnu/bin/ -B/usr/x86_64-linux-gnu/lib/ -isystem > /usr/x86_64-linux-gnu/include -isystem /usr/x86_64-linux-gnu/sys-include > -isystem /<>/build/sys-include-o conftest -g -O2 > -fprofile-use -static-libstdc++ -static-libgcc -Wl,-z,relro conftest.c >&5 > conftest.c:120:6: warning: conflicting types for built-in function 'vfprintf' > char vfprintf (); > ^ > configure:6142: $? = 0 > configure:6142: result: yes > configure:6142: checking for vprintf > configure:6142: /<>/build/./prev-gcc/xgcc > -B/<>/build/./prev-gcc/ -B/usr/x86_64-linux-gnu/bin/ > -B/usr/x86_64-linux-gnu/bin/ -B/usr/x86_64-linux-gnu/lib/ -isystem > /usr/x86_64-linux-gnu/include -isystem /usr/x86_64-linux-gnu/sys-include > -isystem /<>/build/sys-include-o conftest -g -O2 > -fprofile-use -static-libstdc++ -static-libgcc -Wl,-z,relro conftest.c >&5 > conftest.c:121:6: warning: conflicting types for built-in function 'vprintf' > char vprintf (); > ^ > configure:6142: $? = 0 > configure:6142: result: yes > configure:6142: checking for vsnprintf > configure:6142: /<>/build/./prev-gcc/xgcc > -B/<>/build/./prev-gcc/ -B/usr/x86_64-linux-gnu/bin/ > -B/usr/x86_64-linux-gnu/bin/ -B/usr/x86_64-linux-gnu/lib/ -isystem > /usr/x86_64-linux-gnu/include -isystem /usr/x86_64-linux-gnu/sys-include > -isystem /<>/build/sys-include-o conftest -g -O2 > -fprofile-use -static-libstdc++ -static-libgcc -Wl,-z,relro conftest.c >&5 > conftest.c:122:6: warning: conflicting types for built-in function 'vsnprintf' > char vsnprintf (); > ^ > configure:6142: $? = 0 > configure:6142: result: yes > configure:6142: checking for vsprintf > configure:6142: /<>/build/./prev-gcc/xgcc > -B/<>/build/./prev-gcc/ -B/usr/x86_64-linux-gnu/bin/ > -B/usr/x86_64-linux-gnu/bin/ -B/usr/x86_64-linux-gnu/lib/ -isystem > /usr/x86_64-linux-gnu/include -isystem /usr/x86_64-linux-gnu/sys-include > -isystem /<>/build/sys-include-o conftest -g -O2 > -fprofile-use -static-libstdc++ -static-libgcc -Wl,-z,relro conftest.c >&5 > conftest.c:123:6: warning: conflicting types for built-in function 'vsprintf' > char vsprintf (); > ^ > configure:6142: $? = 0 > configure:6142: result: yes > configure:6142: checking for waitpid > configure:6142: /<>/build/./prev-gcc/xgcc > -B/<>/build/./prev-gcc/ -B/usr/x86_64-linux-gnu/bin/ > -B/usr/x86_64-linux-gnu/bin/ -B/usr/x86_64-linux-gnu/lib/ -isystem > /usr/x86_64-linux-gnu/include -isystem /usr/x86_64-linux-gnu/sys-include > -isystem /<>/build/sys-include-o conftest -g -O2 > -fprofile-use -static-libstdc++ -static-libgcc -Wl,-z,relro conftest.c >&5 > configure:6142: $? = 0 > configure:6142: result: yes > configure:6142: checking for setproctitle > configure:6142: /<>/build/./prev-gcc/xgcc > -B/<>/build/./prev-gcc/ -B/usr/x86_64-linux-gnu/bin/ > -B/usr/x86_64-linux-gnu/bin/ -B/usr/x86_64-linux-gnu/lib/ -isystem > /usr/x86_64-linux-gnu/include -isystem /usr/x86_64-linux-gnu/sys-include > -isystem /<>/build/sys-include-o conftest -g -O2 > -fprofile-use -static-libstdc++ -static-libgcc -Wl,-z,relro conftest.c >&5 > /tmp/ccXFqm07.o: In function `main': > /<>/build/libiberty/conftest.c:136: undefined reference to > `setproctitle' > collect2: error: ld returned 1 exit status The full build log is available from: http://aws-logs.debian.net/2016/11/18/gcc-5_5.4.1-3_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
