We're getting an crash with go when I try and enable go support for ARM in the swig package. http://koji.fedoraproject.org/koji/taskinfo?taskID=6780663 It's currently just a scratch build as I obviously can't push it if it fails. checking Examples/go/callback checking Examples/go/class unexpected fault address 0x40440000 fatal error: fault [signal 0xb code=0x1 addr=0x40440000 pc=0x40440000] goroutine 1 [running]: runtime.throw(0x15691f) /usr/lib/golang/src/pkg/runtime/panic.c:464 +0x5c fp=0xb6ba5f7c runtime: unexpected return pc for runtime.sigpanic called from 0x40440000 runtime.sigpanic() /usr/lib/golang/src/pkg/runtime/os_linux.c:237 +0xa8 fp=0xb6ba5f88 goroutine 3 [syscall]: runtime.goexit() /usr/lib/golang/src/pkg/runtime/proc.c:1394 checking Examples/go/constants make[3]: *** [go_run] Error 2 make[2]: *** [check] Error 2 make[1]: *** [class.actionexample] Error 2 checking Examples/go/enum checking Examples/go/extend checking Examples/go/funcptr checking Examples/go/multimap checking Examples/go/pointer checking Examples/go/reference checking Examples/go/simple checking Examples/go/template checking Examples/go/variables
Wacky. I wonder what code it is compiling/running to get a panic on a syscall ... Peter, code you paste the code from the swig class.actionexample ? (In reply to Peter Robinson from comment #0) > We're getting an crash with go when I try and enable go support for ARM in > the swig package. > > http://koji.fedoraproject.org/koji/taskinfo?taskID=6780663 > > It's currently just a scratch build as I obviously can't push it if it fails. > > checking Examples/go/callback > checking Examples/go/class > unexpected fault address 0x40440000 > fatal error: fault > [signal 0xb code=0x1 addr=0x40440000 pc=0x40440000] > goroutine 1 [running]: > runtime.throw(0x15691f) > /usr/lib/golang/src/pkg/runtime/panic.c:464 +0x5c fp=0xb6ba5f7c > runtime: unexpected return pc for runtime.sigpanic called from 0x40440000 > runtime.sigpanic() > /usr/lib/golang/src/pkg/runtime/os_linux.c:237 +0xa8 fp=0xb6ba5f88 > goroutine 3 [syscall]: > runtime.goexit() > /usr/lib/golang/src/pkg/runtime/proc.c:1394 > checking Examples/go/constants > make[3]: *** [go_run] Error 2 > make[2]: *** [check] Error 2 > make[1]: *** [class.actionexample] Error 2 > checking Examples/go/enum > checking Examples/go/extend > checking Examples/go/funcptr > checking Examples/go/multimap > checking Examples/go/pointer > checking Examples/go/reference > checking Examples/go/simple > checking Examples/go/template > checking Examples/go/variables
(In reply to Vincent Batts from comment #1) > Wacky. I wonder what code it is compiling/running to get a panic on a > syscall ... > > Peter, code you paste the code from the swig class.actionexample ? Can't you retrieve it from the .src.rpm?
Peter Robinson, Is this still an issue on swig-3.0.2-1? looks like Swig is building clean lately http://koji.fedoraproject.org/koji/packageinfo?packageID=400 (In reply to Peter Robinson from comment #0) > We're getting an crash with go when I try and enable go support for ARM in > the swig package. > > http://koji.fedoraproject.org/koji/taskinfo?taskID=6780663 > > It's currently just a scratch build as I obviously can't push it if it fails. > > checking Examples/go/callback > checking Examples/go/class > unexpected fault address 0x40440000 > fatal error: fault > [signal 0xb code=0x1 addr=0x40440000 pc=0x40440000] > goroutine 1 [running]: > runtime.throw(0x15691f) > /usr/lib/golang/src/pkg/runtime/panic.c:464 +0x5c fp=0xb6ba5f7c > runtime: unexpected return pc for runtime.sigpanic called from 0x40440000 > runtime.sigpanic() > /usr/lib/golang/src/pkg/runtime/os_linux.c:237 +0xa8 fp=0xb6ba5f88 > goroutine 3 [syscall]: > runtime.goexit() > /usr/lib/golang/src/pkg/runtime/proc.c:1394 > checking Examples/go/constants > make[3]: *** [go_run] Error 2 > make[2]: *** [check] Error 2 > make[1]: *** [class.actionexample] Error 2 > checking Examples/go/enum > checking Examples/go/extend > checking Examples/go/funcptr > checking Examples/go/multimap > checking Examples/go/pointer > checking Examples/go/reference > checking Examples/go/simple > checking Examples/go/template > checking Examples/go/variables
(In reply to Vincent Batts from comment #3) > Peter Robinson, Is this still an issue on swig-3.0.2-1? looks like Swig is > building clean lately > http://koji.fedoraproject.org/koji/packageinfo?packageID=400 Only because go was disabled. I'll retest and update
It still fails. http://koji.fedoraproject.org/koji/taskinfo?taskID=7058479 You can test yourself with the following change to the swig spec file: diff --git a/swig.spec b/swig.spec index 7c1b180..5bc6105 100644 --- a/swig.spec +++ b/swig.spec @@ -6,7 +6,7 @@ %{!?lualang:%global lualang 1} %{!?rubylang:%global rubylang 1} -%ifarch aarch64 %{arm} ppc64le ppc %{power64} s390 s390x +%ifarch aarch64 ppc %{power64} s390 s390x %{!?golang:%global golang 0} %{!?Rlang:%global Rlang 0} %{!?javalang:%global javalang 0}
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
(In reply to Peter Robinson from comment #5) > It still fails. > > http://koji.fedoraproject.org/koji/taskinfo?taskID=7058479 > > You can test yourself with the following change to the swig spec file: > > diff --git a/swig.spec b/swig.spec > index 7c1b180..5bc6105 100644 > --- a/swig.spec > +++ b/swig.spec > @@ -6,7 +6,7 @@ > %{!?lualang:%global lualang 1} > %{!?rubylang:%global rubylang 1} > > -%ifarch aarch64 %{arm} ppc64le ppc %{power64} s390 s390x > +%ifarch aarch64 ppc %{power64} s390 s390x > %{!?golang:%global golang 0} > %{!?Rlang:%global Rlang 0} > %{!?javalang:%global javalang 0} Peter, there has been a lot of upstream improvements on arm. Can you retest?
> Peter, there has been a lot of upstream improvements on arm. Can you retest? It's going to take me a while to get to this, you could just drop the %{arm} conditional and do a scratch build to see if it works. In actual fact looking at the conditional it could likely be dropped entirely as we have golang on aarch64/Power64 since then and gcc-go on s390(x) too so in theory they should be supportable on all of the arches now. Adding the other arches as someone might have some cycles to review them.
> Peter, there has been a lot of upstream improvements on arm. Can you retest? So kicked off some scratch builds with this diff enabling it on ppc64/ppc64le/s390x/aarch64/armv7. -%ifarch aarch64 %{arm} %{mips} ppc64le ppc %{power64} s390 s390x +%ifarch %{mips} ppc s390 %{!?golang:%global golang 0} aarch64: looks to be some java issues http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=3537366 power64: golang issues http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3366693 s390x: looks to needs some conditionals to use gcc-go http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=2221906 ARMv7: still building http://koji.fedoraproject.org/koji/taskinfo?taskID=13973607 I suspect it's probably worthwhile to untangle the golang/java/R enable options, I've added it to my list to investigate but I don't have much time and it's really something the maintainer should be doing.
ARMv7 appears to have completed: http://koji.fedoraproject.org/koji/taskinfo?taskID=13973607
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.