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

[John Paul Adrian Glaubitz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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.

> 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.

>> 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.

And I felt putting pressure was adequate as not having the patch in
meant that more and more packages would fail to build meaning the
sparc64 port would fall behind more and more. And falling behind
in the build queue means more and more packages will need manual
builds making the whole porting efforts I have invested dissolve
into air immediately.

> 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.

> 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. Once systemd is linked with
bfd, all the other packages build fine. If systemd is linked with
bfd, lots of packages immediately fail with:

/usr/bin/ld: //lib/sparc64-linux-gnu/libsystemd.so.0: Only registers
%g[2367] can be declared using STT_REGISTER
//lib/sparc64-linux-gnu/libsystemd.so.0: error adding symbols: No such
file or directory
collect2: error: ld returned 1 exit status
make[2]: *** [dbus] Error 1

It's perfectly easy to reproduce and can be triggered by using a
systemd package linked with gold in the build depends instead
of bfd. I don't know which other arguments I should bring up
really.

> 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 ...

Adrian

- -- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWO3VYAAoJEHQmOzf1tfkTB8kP/idgOjKoxhMa+7q35EIqCbVY
PkgPPE41XT643jJoO9W9SnvNmwAzO/pZ4ycODdpvvUXtwCiXORP8ln0F/0hs6YlZ
HX3pc9kS7F75B5pWW2v+M/loRa5r1Q+G9p7iUHYa29jAMkdQlyowjMeVi0wSskxt
dr2O/tYLv+29zlgVJrfn7YOxVqX2rzOCWYFqB/uAv1QFHFsjVD+v3J7BC8bihYIT
NauJOVTvFMYS/ymeNGVV0QJV+EG2ydH5b8pPO8N1n3cVQLvD/elASa7L9gPvUqmb
WKoBVtb1eyHBajhtcRN4EWLkHxpynCZlhR3fn2GySAk8Pv2UXFSkK2kg6HHcA2WV
pbJcGbT3jAaJsupZ1qCCCJ3/lubEm21FtbohDlwXJoZJQK+3cmKfb+txuOWp1drl
FC04uvwlWlLc2y1f8pHl9VbmEzuZE/KY2t4VuZ4gV+sQ06fX1Pn4Fnc1mdrLSMPd
JUxiS71GvC/wWfkJbMgVS7Geossr6zY/6fJFYweqvFE7LfzK/ao+UV4n6+n93F/V
gBFf+xniSJ4PPQO8uWbetwFTQEDj9DloQrwuAB8oIIHeJ4IjeFgQeymLVtAu/T5A
QX6MORHO03ONSKhvF1SzRYRRgGCRbWUlEB1Dac+ZdqrKbrc4iszlxaKgXHPfz19i
BfDtmGvDw/72hSsQjXca
=T/EJ
-----END PGP SIGNATURE-----