use gcc-go instead of go #73
Labels
No Label
blocked upstream
bug
build-failure
duplicate
enhancement
help wanted
informational
invalid
invalid/corrupt package
packaging issue
priority: high
question
support
wontfix
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: ALHP/ALHP.GO#73
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
As the arch wiki for go said, gcc-go might offer better optimizations, and on some of my testing less build time.
I did some research on this.
gcc-go
is certainly the better option overall, but one of its major downsides is that it falls behind in what go-version it supports quite quickly because it's dependent on the gcc release cycle.That aside, we would need some testing if a 'simple' replace of the
go build
would be enough to build withgcc-go
or not.[Suggestion] use gcc-go instead of goto use gcc-go instead of go@anonfunc Go programs usually specifify the minimum go version they need. So if the program is specifing something below the go version gcc-go can provide we could try to build it with gcc-go. If it's successfull we could offer the package, if not just retry on the next version.
I think eventually most programs will support both. :)