-----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 - [email protected] `. `' Freie Universitaet Berlin - [email protected] `- 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-----
