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.
Reply to: