Control: tags -1 - patch

James, based on your feedback, I tried to apply these revisions on the branch,
had to update some of these, and got a failed build. I'm not intending to work
on this, and would like to ask you to prepare a tested debdiff for a backport or
to get the backport upstream if you want to include the libgo port into the
gcc-6 Debian packages.


 proposed patches, please really check
On 16.10.2016 19:40, James Clarke wrote:
> Control: tags -1 - help + patch
> Hi Matthias,
> On Thu, Oct 13, 2016 at 01:50:43PM +0200, Matthias Klose wrote:
>> Control: tags -1 + help
>> Control: tags -1 - patch
>> James, please could you name the revisions in the GCC subversion repository?
>> Afaics these are r241084, r241077, r241051.  Even better, could you test and
>> propose this backport upstream?
> To confirm, they are the following revisions:
> * r241171 (sparc64 relocations, e1fc2925 in go master, now also in
>            gofrontend/gccgo)
> * r241084 (don't use pt_regs; unnecessary, and seemingly not defined by
>            the included headers on arm64)
> * r241072 (make rawClone no_split_stack)
> * r241051 (fix getrandom on sparc64 and clone on sparc*)
> * r240457 (add getrandom for MIPS/SPARC)
> We've been using the latest gcc-6 package with these patches (other than
> no_split_stack and pt_regs fixups) applied on top for sparc64 (uploaded
> to unreleased) for the past few days, and the only packages which fail
> to build seem to be because Debian currently has an out-of-date x/sys
> package without sparc64 definitions. I haven't been aware of any
> regressions.
> Ian: I imagine the getrandom and elf changes would be fine for gcc-6,
> but what about the clone changes? I can understand if that's too
> invasive, but backporting would be great.
> Regards,
> James
>> On 12.10.2016 23:35, James Clarke wrote:
>>> Source: gcc-6
>>> Version: 6.2.0-6
>>> User:
>>> Usertags: sparc64
>>> X-Debbugs-Cc:
>>> Tags: patch fixed-upstream
>>> Hi,
>>> Could you please backport the patches listed below so that we can have a
>>> working gccgo? They fix the (minor) issue of using the wrong syscall
>>> number for getrandom (if code uses it), add support for sparc64's
>>> relocations, and also the following error when running go build:
>>>     /usr/bin/sparc64-linux-gnu-gccgo-6: wait: no child processes
>>>     /usr/bin/sparc64-linux-gnu-gccgo-6: exit status 1
>>> The patches are:
>>>     (not yet pulled into gofrontend's libgo)
>>> With all but the last patch (a minor fixup after my patches), I have
>>> been able to successfully build and run go programs on sparc64.
>>> Regards,
>>> James

Reply via email to