Bug#803474: src:systemd: Please use the default linker instead of gold on sparc64

[John Paul Adrian Glaubitz]

On Nov 5, 2015, at 5:31 PM, Michael Biebl <biebl at debian.org> wrote:
> 
>> Am 05.11.2015 um 16:27 schrieb John Paul Adrian Glaubitz:
>>> On 11/05/2015 03:46 PM, Michael Biebl wrote:
>>> I see that other packages use gold as well (e.g.
>>> qtbase-opensource-src), codesearch.d.n turns up quite a few more. 
>>> Are you sure that this only affects systemd?
>> 
>> So far, yes.
> 
> How do you know that? Have you actually checked those packages (and
> their rdeps)?

Well, by reading the build logs of packages that FTBFS'd and this issue has always only been visible when linking against libsystemd or libudev.

Granted, I haven't rebuilt all 20,000 source packages and checked the build logs but, frankly, this would be asking for too much.

>>> Or is this specific due to the usage of LTO or the usage of other 
>>> specific features? If so, have you checked which one that are and
>>> if that affects other packages as well?
>> 
>> Probably. I'm not too much an experts when it comes to binutils. I
>> know someone who is though.
> 
> Ok, knowing what the actual problem is would certainly be helpful in
> deciding what should be done.
> 
> At least personally I like to understand the issue before applying a
> workaround.

Frankly, I don't understand what your problem with that *temporary* fix is. It's clearly fixing the issue with one of the most important core packages and its rdepends. What other arguments do you need to understand that we need this fix?

>>>> Really, this workaround is currently the only chance we have to
>>>> be able to continue working on the ports.
>> 
>>> I understand that fixing binutils might take some time. Then again,
>>> the gold linker on sparc has been known broken for over a year, so
>>> I don't quite get the sudden hurry (i.e. escalating this within 3
>>> days without giving us a chance to respond, especiallly since I've
>>> been away over the weekend. I have to say I'm quite disturbed by
>>> that. But let's leave it at that)
>> 
>> The hurry can be explained easily. As I explained before, systemd
>> Debian was carrying a patch which worked around the issue and
>> apparently, you, the systemd maintainers assumed this patch was
>> necessary for gudev only and hence it was removed when gudev was
>> split out of the systemd package. Around that time, packages started
>> to fail to build and I couldn't explain why. It was not until
>> recently when Jose Marchesi asked me to have systemd link with
>> gold that I discovered that the reason it problem occurred so
>> abruptly was the fact that the patch was dropped recently.
> 
> As recently as May 2015, so it's been broken for almost half a year.
> So no, I don't quite understand the way this was approached from your
> side. But as said, let's leave it at that.

Uhm, yeah, I had other issues in the meantime. It doesn't diminish my arguments in any way. The fact is, I just recently discovered the connection between systemd and gold.

>>> I'm also not convinced yet that applying this workaround to systemd
>>> is the only available option and the correct one we should use.
>> 
>> Well, if you have a better plan which does not involve requiring
>> to fix binutils over night, please go ahead. I'd be more than
>> curious to know.
> 
> Depending on what actually is broken, a workaround could also be to make
> that functionality in gold on sparc a nop instead of generating broken code.

Which would probably involve much more patching and hacking than just using the working linker in the first place.

> Don't you think we should first understand what is broken and what the
> impact is?

Well, gold is missing support for SPARCs STT-REGISTER and I don't think it's trivial to patch gold in a simple way that it would just work.

I can ask an expert to post a comment to this bug report if you really need that though.

>>> If other packages are affected as well, it sounds to me that we
>>> should rather add a workaround to binutils until a proper solution
>>> has been developed.
>> 
>> No other packages are directly affected.
> 
> Again, how do you know that?

By reading build logs. There is no real magic involved here. I'm a buildd maintainer and in that function I read build logs of packages that FTBFS'd and analyzed the origin of the FTBFS.

>>> If it's only systemd, by all means let's merge that patch. But so
>>> far, I haven't seen a thorough assessment of this issue which would
>>> have convinced me in that direction. We certainly don't want to
>>> obstruct any efforts you do on the sparc port, but let's first be
>>> certain that this workaround is the proper one.
>> 
>> It's the work-around suggested by one of the SPARC developers at Oracle.
>> So ...
> 
> So, this doesn't necessarily mean other packages aren't affected.
> Depending on how many are, my answer will be different.

Well, once systemd is fixed and all its rdepends build fine, the list of packages that FTBFS will actually reduce by quite margin meaning I can more easily see whether other packages are affected or not.

However, to my best current knowledge, no other packages are affected from reading dozens of logs of packages that FTBFS'd.

Adrian

> Michael
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>