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

[Michael Biebl]

Control: reassign -1 binutils
Control: retitle -1 please remove gold linker on sparc*

Hi Adrian,

thanks for your detailed explanation.
Given those findings, I'm going to re-assign this bug to binutils (CCing
the complete message so doko has some more context), asking for the
removal of the gold linker on sparc.

Regards,
Michael

Am 08.11.2015 um 23:41 schrieb John Paul Adrian Glaubitz:
> On 11/08/2015 11:15 PM, Michael Biebl wrote:
>> A quick test-build, where I removed /usr/lib/gold-ld/ 
>> /usr/bin/gold /usr/bin/ld.gold
> 
>> was successful on amd64. So this approach might work. Instead of
>> removing gold on sparc, it might be better though to simply rename
>> it to something like gold-experimental or so. So users/devs who
>> explicitly want to test the linker could do so easily.
> 
> It's also successful on sparc64 and after some more research, I came
> to the conclusion that we should, in fact, disable gold on sparc*
> completely which I have already done in the unreleased suite. I will
> ask Matthias to disable gold on sparc* in the binutils package in
> unstable.
> 
>> Btw, #790556 is marked as fixed-upstream.
> 
> I know. Me and a good friend were involved fixing the issue. However,
> this was merely a bug while ...
> 
>> issues. The one involving STT-REGISTER is, as you are well aware,
>> not fixed upstream.
> 
> ... this is absolutely non-trivial as it turns out.
> 
> To briefly explain the issue as Michael Karcher (who helped debugging
> #790556) explained it to me: STT_REGISTER is actually called
> STT_SPARC_REGISTER which is a so-called pseudo or dummy symbol in
> the ELF object file. This dummy symbol is used to tell the linker
> how either of the four global registers %2, %3, %6 or %7 are used
> within a certain object file (either not used, for temporary variables
> or for a third case which I already forgot). The use case is encoded
> into the address field assigned to the symbol in the ELF object file.
> 
> At the same time, the symbol is marked as undefined. Now, the problem
> is that gold does not support this type of dummy symbol at all and
> is actually confused that a symbol is undefined and has a non-zero
> address value in the address field at the same time and then writes
> just zero into the address field which in turn results in the known
> error message since any value other than 2,3 6 or 7 is not allowed:
> 
>   Only registers %g[2367] can be declared using STT_REGISTER
> 
> 
> At first look it might look trivial to add support for
> STT_SPARC_REGISTER in gold to the sparc backend. But the problem is
> that these dummy symbols cannot be stored in gold's internal
> representation of an ELF object file which means that parts of
> the non-architecture-specific code of gold have to be rewritten
> which takes a while [1].
> 
> To cut a long story short: The gold developers did not implement
> a fully spec-compliant SPARC backend meaning that potentially
> anything linked with gold on sparc* is broken. Which is why gold
> should not be used on sparc* at all for the time being.
> 
> We can therefore either close this bug report or reassign it
> to binutils, tracking binutils upstream PR target/19019.
> 
> Thanks for being stubborn enough and having me do more extensive
> research :).
> 
> Cheers,
> Adrian
> 
>> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=19019#c18


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



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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

[Debian Bug Tracking System]

Processing control commands:

> tags -1 = moreinfo
Bug #803474 [systemd] src:systemd: Please use the default linker instead of 
gold on sparc and sparc64
Added tag(s) moreinfo; removed tag(s) patch and wontfix.

-- 
803474: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803474
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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

[Michael Biebl]

Control: tags -1 = moreinfo

Marking as moreinfo for now (and removing wontfix) since the decision
which workaround to apply (for binutils directly or systemd/affected
packages) is not yet decided.


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



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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

[Michael Biebl]

Hi,

Am 07.11.2015 um 00:28 schrieb John Paul Adrian Glaubitz:
> On 11/05/2015 06:14 PM, Michael Biebl wrote:
>> Am 05.11.2015 um 17:53 schrieb John Paul Adrian Glaubitz:
>>> On Nov 5, 2015, at 5:31 PM, Michael Biebl 
>>> wrote:
> 
 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.
> 
>> Well, depending on how broken gold on sparc* actually is, wouldn't
>> it be an option to simply make /usr/bin/ld.gold a symlink to
>> ld.bfd? That workaround would be trivial to implement as well.
> 
> I'll try something similar now. I'll build binutils on sparc* explicitly
> without gold now. Do you know whether systemd will still build fine on
> systems where gold is not available at all or will it fail?
> 
> If systemd will still build fine in such cases and default to bfd, then
> I'll happily patch binutils instead.

A quick test-build, where I removed
 /usr/lib/gold-ld/
 /usr/bin/gold
 /usr/bin/ld.gold

was successful on amd64. So this approach might work.
Instead of removing gold on sparc, it might be better though to simply
rename it to something like gold-experimental or so.
So users/devs who explicitly want to test the linker could do so easily.


>> This would have the additional benefit that this workaround would
>> apply for all packages that use gold and this workaround can be
>> dropped exactly when gold has been fixed.
> 
> Yeah, I'll look into that now. I have done more digging and it actually
> seems that gold results in Qt5 FTBFS on sparc64 now. But I haven't fully
> confirmed that now.
> 
 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
> 
>> I don't actually know what that is. Does that mean every executable
>> that has been built with gold is broken on sparc?
> 
> Looks like that. I'll do some more research now.

Btw, #790556 is marked as fixed-upstream. Apparently there are multiple
issues. The one involving STT-REGISTER is, as you are well aware, not
fixed upstream. I think it would be better to track those two issues
separately. Would be great if you can file a separate bug report against
binutils for that.

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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/08/2015 11:15 PM, Michael Biebl wrote:
> A quick test-build, where I removed /usr/lib/gold-ld/ 
> /usr/bin/gold /usr/bin/ld.gold
> 
> was successful on amd64. So this approach might work. Instead of
> removing gold on sparc, it might be better though to simply rename
> it to something like gold-experimental or so. So users/devs who
> explicitly want to test the linker could do so easily.

It's also successful on sparc64 and after some more research, I came
to the conclusion that we should, in fact, disable gold on sparc*
completely which I have already done in the unreleased suite. I will
ask Matthias to disable gold on sparc* in the binutils package in
unstable.

> Btw, #790556 is marked as fixed-upstream.

I know. Me and a good friend were involved fixing the issue. However,
this was merely a bug while ...

> issues. The one involving STT-REGISTER is, as you are well aware,
> not fixed upstream.

... this is absolutely non-trivial as it turns out.

To briefly explain the issue as Michael Karcher (who helped debugging
#790556) explained it to me: STT_REGISTER is actually called
STT_SPARC_REGISTER which is a so-called pseudo or dummy symbol in
the ELF object file. This dummy symbol is used to tell the linker
how either of the four global registers %2, %3, %6 or %7 are used
within a certain object file (either not used, for temporary variables
or for a third case which I already forgot). The use case is encoded
into the address field assigned to the symbol in the ELF object file.

At the same time, the symbol is marked as undefined. Now, the problem
is that gold does not support this type of dummy symbol at all and
is actually confused that a symbol is undefined and has a non-zero
address value in the address field at the same time and then writes
just zero into the address field which in turn results in the known
error message since any value other than 2,3 6 or 7 is not allowed:

Only registers %g[2367] can be declared using STT_REGISTER


At first look it might look trivial to add support for
STT_SPARC_REGISTER in gold to the sparc backend. But the problem is
that these dummy symbols cannot be stored in gold's internal
representation of an ELF object file which means that parts of
the non-architecture-specific code of gold have to be rewritten
which takes a while [1].

To cut a long story short: The gold developers did not implement
a fully spec-compliant SPARC backend meaning that potentially
anything linked with gold on sparc* is broken. Which is why gold
should not be used on sparc* at all for the time being.

We can therefore either close this bug report or reassign it
to binutils, tracking binutils upstream PR target/19019.

Thanks for being stubborn enough and having me do more extensive
research :).

Cheers,
Adrian

> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=19019#c18

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

iQIcBAEBCAAGBQJWP8+VAAoJEHQmOzf1tfkTUFEP/ibASYSiET5MOA/syB0DZPRY
hgN4PZytPXL+hkQrDlYHRRoNp8JurFItbmZo/LlapA9JGYz9TuzDyOk10+l1Pwpi
p4QeOp0b1D0qNvHnqX1PcJuQzugmZfG8PNTc6jmSLYvzJ+hi5UKghrpiQm0G84f8
pcfqHY48FBLe4QPtKsA1awdczP6wMTNGjAGmRnFEuvAhE3c6h7Mg2IZatGr8IBvn
Q+kB0Engd/xMuiYz9blAmS3E7auWNsETuZlumVe4cNqW363fgkkCzRVD1wsFtX5G
cFTSKGLzQ3xNNkneEZxfw9tcxfXMLf0wJgD7lQu+m+DMasM0OJEUH6PlMMnYMF47
DOOZxHw7JQEhSn0DakaadfZU98dEdgRSU63lchQZQw3pp36T9ZsNKSfhPynta28/
nlXRjeIXe82IgLK0+HRoF00dDmNOK3qhKf2cYtn8pWvbrsSdwVzSzCp+C3MbmXqL
a3VeNlr2nK4dFs4s+OnkBcJRlsokQsvYc7a0bqL6OsRUEtE4k+IumB5XV1ANFRSk
6rUbkkKWnGoM7QaPba1K/5QAzpmEX1ID/86hCVC2OIj75cNDNT+gkGUG4d6ZGTab
rhmptO2S3hEKYcGETUpVuz/kkkKNDbC9mvQZ1rBiPKf9s+3qUxq+q7K99nhZ5NMn
iU8jpMlFmr3JCBFA8HV1
=Z05P
-END PGP SIGNATURE-

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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 06:14 PM, Michael Biebl wrote:
> Am 05.11.2015 um 17:53 schrieb John Paul Adrian Glaubitz:
>> On Nov 5, 2015, at 5:31 PM, Michael Biebl 
>> wrote:
> 
>>> 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.
> 
> Well, depending on how broken gold on sparc* actually is, wouldn't
> it be an option to simply make /usr/bin/ld.gold a symlink to
> ld.bfd? That workaround would be trivial to implement as well.

I'll try something similar now. I'll build binutils on sparc* explicitly
without gold now. Do you know whether systemd will still build fine on
systems where gold is not available at all or will it fail?

If systemd will still build fine in such cases and default to bfd, then
I'll happily patch binutils instead.

> This would have the additional benefit that this workaround would
> apply for all packages that use gold and this workaround can be
> dropped exactly when gold has been fixed.

Yeah, I'll look into that now. I have done more digging and it actually
seems that gold results in Qt5 FTBFS on sparc64 now. But I haven't fully
confirmed that now.

>>> 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
> 
> I don't actually know what that is. Does that mean every executable
> that has been built with gold is broken on sparc?

Looks like that. I'll do some more research now.

Adrian

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

iQIcBAEBCAAGBQJWPTeQAAoJEHQmOzf1tfkT2W0P/1vlMSNxpgbhb8I5pwsgB+ux
rh0SHBe21ZiuCIvT9Ei7g0yu0Nk3zpDcr5GncfjbfRxNyQw5V4NxCkIT4sejoO5z
HQ7OyD55CKX/in2+/UBUlTOCCJya8holec/OeWAg88jIypzClWA2KX3GUnt0RczW
Kpo2+zIju914uEgHQEjVuvcMukG/2pZjWS6IrpkfBvwietaCAYtZyMlPFFs3sNhk
8+5Bcw2IcsUI/V+MiPMdYRPKouDkZezS2MwqNZKa0bxhocvztHfeufPjjxymhJBN
+9HONvo5KxYVGSTdyrMYOQrLoga6h2QfeX6fVjgzFdFngDF3fBQ0ikCLpWs8ktKQ
/JiGjeaq2SGXKlGhNuE+/hjVcSrnhWZkhKjaR+HlYDkDspc9XOsZasbSEmdUquMr
Cf27HedCfkQdGyb5l1piFpv5Vo3xDieCK9BkYlc3YLoqAbBH8z9ND7/2EqV8uN4F
4VTd1ag3Q9809t0MXYrFIyl7avTz0jq0BmatLjbnQuhxRd89a7txxH8wNiWlJIsz
GelVpOX4ZAI7g4hISgjXAPBuoi4pNHb04fT1CPR3ijYj/+7mlIADvD4Yc8e2QfNG
h8djZ6hPfMiNdjifItMzL1sd0Rldt95NuddVNNQx+zIRyFZpEqYk+5vzrsEiBRFE
gfOdT65h8tlrhqHuA9fD
=9F9W
-END PGP SIGNATURE-

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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

[Michael Biebl]

Am 05.11.2015 um 17:53 schrieb John Paul Adrian Glaubitz:
> On Nov 5, 2015, at 5:31 PM, Michael Biebl  wrote:

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

Well, depending on how broken gold on sparc* actually is, wouldn't it be
an option to simply make /usr/bin/ld.gold a symlink to ld.bfd?
That workaround would be trivial to implement as well.

This would have the additional benefit that this workaround would apply
for all packages that use gold and this workaround can be dropped
exactly when gold has been fixed.

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

I don't actually know what that is. Does that mean every executable that
has been built with gold is broken on sparc?

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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

[Michael Biebl]

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)?

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


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

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

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


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

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

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



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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

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 - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@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-

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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

[Michael Biebl]

Am 30.10.2015 um 21:56 schrieb John Paul Adrian Glaubitz:
> On 10/30/2015 08:35 PM, Michael Biebl wrote:
>>> The problem is that this particular fix needs larger amount of
>>> work and isn't actually trivial meaning that unless you guys are
>>> helping us and apply this (temporary) fix to systemd, we will not
>>> be able to do any sensible work on either of the ports for a very
>>> long time!
> 
>> Why not?
> 
> Because currently any package linking against libsystemd or libudev,
> *will* fail to build from source on sparc and sparc64. In return, these
> packages have many reverse dependencies meaning that many packages in
> sparc64 are currently BD-Uninstallable.

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?

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?

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

I'm also not convinced yet that applying this workaround to systemd is
the only available option and the correct one we should use.

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.

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.


Regards,
Michael




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



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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

[John Paul Adrian Glaubitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

On 10/30/2015 09:56 PM, John Paul Adrian Glaubitz wrote:
> Because currently any package linking against libsystemd or 
> libudev, *will* fail to build from source on sparc and sparc64. In 
> return, these packages have many reverse dependencies meaning that 
> many packages in sparc64 are currently BD-Uninstallable.

Is there any chance now that this fix can be temporarily merged into
the systemd package until the larger work on binutils/gold to implement
support for the STT_REGISTER has been finished?

We really don't have any chance to continue working on this port without
this hotfix as *all* packages which link against either libsystemd
or libudev will fail with linker issues such as:

configure: error: udev selected but libudev not found
checking for udev_new in -ludev... no
"tail -v -n +0 config.log"
==> config.log <==
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by util-linux configure 2.27, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ./configure --build=sparc64-linux-gnu --prefix=/usr
- --includedir=${prefix}/include --mandir=${prefix}/share/man
- --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
- --disable-silent-rules --libdir=${prefix}/lib/sparc64-linux-gnu
- --libexecdir=${prefix}/lib/sparc64-linux-gnu --disable-maintainer-mode
- --disable-dependency-tracking --enable-line
- --libdir=/lib/sparc64-linux-gnu
- --libexecdir=${prefix}/lib/sparc64-linux-gnu --enable-raw
- --with-selinux --enable-partx --with-systemd --with-udev
- --enable-tunelp --enable-static-programs=fdisk,sfdisk,blkid
- --localstatedir=/run --disable-silent-rules --without-python
- --enable-libmount-force-mountinfo --disable-login --disable-nologin
- --disable-su --disable-kill --disable-eject --disable-chfn-chsh

We really need your help on this.

Thank you,

Adrian

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

iQIcBAEBCAAGBQJWN35LAAoJEHQmOzf1tfkTnC8P/3sYeiJfu8vACM+iPyvEEARm
hCFA1aJFSRVgOdVBearw98hQjilgi28A/gL5/Qux79CnBvwBvw4/S2u2nCvR1UIn
SW0d1lb668618GMkJmD2+4wWu2cON47502x35A8H6c1gwLzQOd0Kk+P72E3iRC06
GdTvg7C0R7+XPO7/pA4QysSkSDFZjf4ZGo+Tt2qo1ol/waN/sR9WFn7zg9pT6LLA
hOvfRdC8blV5xMZg6kAQBb7DF2PgrjYs2zPQhbWu7y4/nm4VhfMlwK4HvF46tRzM
T8azgKuRYscZY/YTbi1APd3EjVvEuLqt1Ynx3jbX1JBX6NTAX7eiaSSZ1b/EgBdy
7obbTOdA8kxpRjZ4q5fuGuQkYQRswl1UwfLt0ls15qcv0iTgzCqm51niFQ0AC3Cg
TXIj7aBltIInmdeBYswZb9Exlw09amhP2yXwYzbuPC+Xrynzitq9vQ+sq2Dqa/Kl
Ay0W4rWN0/3epevoqjKYTJqqoNrM0BXG4tyGppn4m++gttLFCcGFenYph3XA76Um
dMj7JACxug3zLZlcCBeszGzA3d62bn/zyePHCpRDOAzVOhUWqNSHBU9VJAXHr26H
cLdfbFpCGtzZlr8bqvCd3EfAkZydTymwlY9xYVtquD8nWfxz6jMDq1498WsYx8ss
zpiXDOtzySdNr4vTrGw6
=WNPj
-END PGP SIGNATURE-

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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

[John Paul Adrian Glaubitz]

Package: systemd
Version: 227-2
Severity: important

Hello!

We're currently having linker issues on sparc64 for packages which link against
libsystemd. This is a result of systemd defaulting to gold instead of ld/bfd.

While there has been an exception in place for sparc [1], this does not cover
sparc64 and there linker problems there still cause lots of headaches for
the sparc64 port.

Could you please change the build system (e.g. rules file) such that it uses
ld/bfd on *both* sparc *and* sparc64 (we are planning to ressurrect sparc
in the future)?

This workaround is necessary because gold is currently missing support for
the STT_REGISTER [2]. This feature is currently being worked on and once
it's there, the workaround can be dropped.

Cheers,
Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760879
> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=19019

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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

[John Paul Adrian Glaubitz]

Control: tags -1 patch

On 10/30/2015 04:26 PM, John Paul Adrian Glaubitz wrote:
> On 10/30/2015 01:59 PM, John Paul Adrian Glaubitz wrote:
>> Could you please change the build system (e.g. rules file) such that it uses
>> ld/bfd on *both* sparc *and* sparc64 (we are planning to ressurrect sparc
>> in the future)?
> 
> More specific, please re-apply this patch [1] and extend it for sparc64
> as well:

Attaching a suggested patch.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- debian/rules.org	2015-10-09 12:54:59.0 +0200
+++ debian/rules	2015-10-30 16:45:06.317724651 +0100
@@ -16,6 +16,13 @@
 export DEB_BUILD_PROFILES += noudeb
 endif
 
+# Linking systemd with the gold linker on sparc/sparc64 currently breaks
+# linking of other binaries against systemd's shared libraries due to a
+# limitation in gold on these architectures (binutils PR target/19019).
+ifneq (,$(findstring $(DEB_BUILD_ARCH), sparc sparc64))
+LD=ld
+endif
+
 CONFFLAGS = \
 	--with-rootprefix= \
 	--with-rootlibdir=/lib/$(DEB_HOST_MULTIARCH) \
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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

[Debian Bug Tracking System]

Processing control commands:

> tags -1 patch
Bug #803474 [systemd] src:systemd: Please use the default linker instead of 
gold on sparc and sparc64
Ignoring request to alter tags of bug #803474 to the same tags previously set

-- 
803474: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803474
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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

[John Paul Adrian Glaubitz]

On 10/30/2015 01:59 PM, John Paul Adrian Glaubitz wrote:
> Could you please change the build system (e.g. rules file) such that it uses
> ld/bfd on *both* sparc *and* sparc64 (we are planning to ressurrect sparc
> in the future)?

More specific, please re-apply this patch [1] and extend it for sparc64
as well:

diff --git a/debian/rules b/debian/rules
index f7effa5..78074ff 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,6 +10,13 @@ ifneq (,$(findstring stage1,$(DEB_BUILD_PROFILES)))
 BOOTSTRAP_DH_FLAGS := -Ngir1.2-gudev-1.0 -Nlibgudev-1.0-0
-Nlibgudev-1.0-dev
 endif

+# sparc/sparc64 must use the bfd linker since gold will
+# will result in broken shared libraries
+ifneq ($(findstring $(DEB_BUILD_ARCH), sparc sparc64),)
+LD=ld
+endif
+
+
 CONFFLAGS = \
--with-rootprefix= \
--with-rootlibdir=/lib/$(DEB_HOST_MULTIARCH) \

This patch was dropped when gudev was removed from systemd upstream
assuming that linking with gold would affect gudev only. However,
it affects linking against libsystemd and libudev in general,
for example usbutils [2]:

/bin/bash ../libtool  --tag=CC   --mode=link gcc  -Os -Wall -g -O2
-fstack-protector-strong -Wformat -Werror=format-security
-I/usr/include/libusb-1.0   -Wl,-z,relro -o usbhid-dump usbhid-dump.o
../lib/libuhd.la -lusb-1.0
libtool: link: gcc -Os -Wall -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -I/usr/include/libusb-1.0 -Wl,-z -Wl,relro -o
usbhid-dump usbhid-dump.o  ../lib/.libs/libuhd.a -lusb-1.0
/usr/bin/ld: //lib/sparc64-linux-gnu/libudev.so.1: Only registers
%g[2367] can be declared using STT_REGISTER
//lib/sparc64-linux-gnu/libudev.so.1: error adding symbols: No such file
or directory
collect2: error: ld returned 1 exit status

Thanks,

Adrian

> [1]
https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/debian/rules?id=8e9833a6f297a0c69180ba4a4801fd1d396b17a9
> [2]
https://buildd.debian.org/status/fetch.php?pkg=usbutils=sparc64=1%3A007-4=171387
-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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

[Michael Biebl]

Am 30.10.2015 um 20:32 schrieb John Paul Adrian Glaubitz:
> On 10/30/2015 07:04 PM, Michael Biebl wrote:
>> I'm against adding such workarounds. Please just get the build
>> toolchain fixed on sparc*.
> 
> The problem is that this particular fix needs larger amount of work and
> isn't actually trivial meaning that unless you guys are helping us and
> apply this (temporary) fix to systemd, we will not be able to do any
> sensible work on either of the ports for a very long time!

Why not?




signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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 10/30/2015 07:04 PM, Michael Biebl wrote:
> I'm against adding such workarounds. Please just get the build
> toolchain fixed on sparc*.

The problem is that this particular fix needs larger amount of work and
isn't actually trivial meaning that unless you guys are helping us and
apply this (temporary) fix to systemd, we will not be able to do any
sensible work on either of the ports for a very long time!

I understand your reservations against such workarounds, but I am also
asking you to understand that - because systemd is such a fundamental
package with so many reverse dependencies - you need to be a bit more
understanding for such requests. It isn't like we have any other
alternatives for the time being, really.

Getting this workaround into the systemd package is really important
for the sparc ports and even upstream systemd has shown more compassion
for such requests. Heck, Lennart is even understanding when I asked
him to make changes to improve systemd on m68k.

Adrian

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

iQIcBAEBCAAGBQJWM8W+AAoJEHQmOzf1tfkTPLIQAJPGDnemo1v+ZhUothxNiCCH
3C1QnuIgNbFPSfycjAqIdEjXS68YzK0PJXCMEG5hSgS7D2dFbhj5GwvgOMIMEmUk
nWShiH7uEI41oNK5JbagbwsgWlkiPNm4qQOVqbhxOADng4SL0Uzv1LWU6cxDRW8A
W6cs98N9sObgX8FA8NrkFe8l5vfuqi1TkS+O6opFZXr8584Tci6xrlQWTskw1lP+
xAJaqeoS8EI/1k1MV1MNB54vAD4xfnC4zsQLSzLRqlu1P8V/QaiLAroXfaugQis7
j9yzpPfmrs0/yye54UXF4+uzeYKkIPVT+1DGu+dr2E5YqKh3qpUsu2OdSpKHmgcB
8iSt6bFz8anutCwL4UVtGAraiUQshg2BPMTVILbOp+3IYx5XZQhzGbsEvbpZon8f
tYXIICn3k8itdPDvHwajED7nYT7NEx86uXP6aLKwoUHJ46WGQenkCnJ1xtdrqfy5
zLnHqL6q53NdCTkwwq6spxN62PxdzVNDhS47tHmTyITQQ9ULXdtlV25viTCsisKX
A5MMhinz9E1Nww/0Zvs874wXFhCuV/aiA4X8811evdJed2WEwPqnvtzza8C8GwfF
tRw/jV75TWi1K5U/0/gxVaE7Du87ZVP0arL9QiTT0jJBW7zozX14BL7pUPlI+lfw
nHNrHhXKXputawj0pHRB
=1B2X
-END PGP SIGNATURE-

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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

[Michael Biebl]

Am 30.10.2015 um 19:04 schrieb Michael Biebl:
> Am 30.10.2015 um 13:59 schrieb John Paul Adrian Glaubitz:
>> Package: systemd
>> Version: 227-2
>> Severity: important
>>
>> Hello!
>>
>> We're currently having linker issues on sparc64 for packages which link 
>> against
>> libsystemd. This is a result of systemd defaulting to gold instead of ld/bfd.
>>
>> While there has been an exception in place for sparc [1], this does not cover
>> sparc64 and there linker problems there still cause lots of headaches for
>> the sparc64 port.
>>
>> Could you please change the build system (e.g. rules file) such that it uses
>> ld/bfd on *both* sparc *and* sparc64 (we are planning to ressurrect sparc
>> in the future)?
> 
> I'm against adding such workarounds. Please just get the build toolchain
> fixed on sparc*.

As for a longer explanation: Adding such workarounds takes the pressure
away to fix it properly. And eventually it is never fixed properly and
the workaround is never removed.
I've seen that too often in the past, like "please disable the
test-suite on kfreebsd-*" so the build succeeds.

Such (temporary) workarounds are ok if the block ongoing transitions for
release architectues.
But for new architectures/ non release architectures I don't see the
need for that. It would just be dishonest granting them such workarounds.

Regards,
Michael




signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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

[Michael Biebl]

Am 30.10.2015 um 13:59 schrieb John Paul Adrian Glaubitz:
> Package: systemd
> Version: 227-2
> Severity: important
> 
> Hello!
> 
> We're currently having linker issues on sparc64 for packages which link 
> against
> libsystemd. This is a result of systemd defaulting to gold instead of ld/bfd.
> 
> While there has been an exception in place for sparc [1], this does not cover
> sparc64 and there linker problems there still cause lots of headaches for
> the sparc64 port.
> 
> Could you please change the build system (e.g. rules file) such that it uses
> ld/bfd on *both* sparc *and* sparc64 (we are planning to ressurrect sparc
> in the future)?

I'm against adding such workarounds. Please just get the build toolchain
fixed on sparc*.




signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers