Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#50433 - [go] provide alternative CGO_ENABLED=0 package

Attached to Project: Community Packages
Opened by c (c) - Thursday, 18 August 2016, 10:30 GMT
Last edited by Alexander F. Rødseth (xyproto) - Monday, 28 November 2016, 23:04 GMT
Task Type Feature Request
Category Packages
Status Closed
Assigned To Alexander F. Rødseth (xyproto)
Pierre Neidhardt (Ambrevar)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
On Linux and OS X go will not produce fully statically linked binaries if CGO_ENABLED hasn't been set 0 when building go's stdlib. Any time one would like to build a random go project with CGO_ENABLED=0, it will complain because it will try to rebuild net.a, which obviously is in /usr and r/o.

Because statically linked binaries are one major advantage of go and this currently doesn't quite work, I request the following feature:

Provide an optional package which was built with CGO_ENABLED=0.

Such a go package would produce binaries that are fully static and don't even depend on libc.
This task depends upon

Closed by  Alexander F. Rødseth (xyproto)
Monday, 28 November 2016, 23:04 GMT
Reason for closing:  None
Comment by Doug Newgard (Scimmia) - Thursday, 18 August 2016, 13:49 GMT
Sounds like something that should be in the AUR.
Comment by c (c) - Tuesday, 23 August 2016, 20:11 GMT
We have libx264 and libx264-10bit and because fully static binaries are a major golang feature, I wouldn't expect to look for this in AUR.
Comment by Doug Newgard (Scimmia) - Wednesday, 24 August 2016, 12:16 GMT
You keep talking up static binaries, but they're crap. Nothing more than bloated security nightmares.

libx264 has nothing at all to do with this.
Comment by Pierre Neidhardt (Ambrevar) - Wednesday, 24 August 2016, 13:47 GMT
Doug, I beg to differ. Static libraries have their pros. See:
http://port70.net/~nsz/32_dynlink.html
http://harmful.cat-v.org/software/dynamic-linking/

The issue does not seem to have an easy fix however, see:
https://dominik.honnef.co/posts/2015/06/go-musl/

The user can install 2 stdlibs by changing the GOROOT. Can the OP see if that is a satisfactory solution?
Comment by Pierre Neidhardt (Ambrevar) - Wednesday, 24 August 2016, 13:55 GMT
Another way is to build your package like this:
To embed the C 'm' library (math):
go build -ldflags '-extldflags "-static -lm"'
Add as many -l flags as you need.
Comment by Doug Newgard (Scimmia) - Wednesday, 24 August 2016, 14:05 GMT
Most of the "advantages" are extremely minor and certainly not worth all of the extra problems they cause. Just think of how many things link to openssl and how many security issues it's had. You'd have to make absolutely certain each and every one was rebuilt with the new version, including upstream binaries you don't have control over.
Comment by Pierre Neidhardt (Ambrevar) - Wednesday, 24 August 2016, 14:32 GMT
Quoting the link regarding dyn libs: "update disaster: bugs can be introduced into all programs at once". Not saying it's worse, but that's not better in any case.
Anyways, let's not drift off too much and try to answer the OP's need.
Comment by Doug Newgard (Scimmia) - Wednesday, 24 August 2016, 14:39 GMT
And can also be fixed in all programs at once. That one's a wash.
Comment by Alexander F. Rødseth (xyproto) - Friday, 26 August 2016, 08:55 GMT
Last year I created an OS X "launcher" app (in Swift), for launching the Algernon web server (written in Go). I had to build it with CGO_ENABLED=0 to make it work correctly.

I've also needed CGO_ENABLED=0 when packaging a Go application for Alpine Linux within a docker container.

For the two above scenarios, it could be handy to have an easy way to test with CGO_ENABLED=0, while running Arch Linux.

Not strictly needed, but nice to have, as a debugging/testing tool. It might be best if it starts out on a package on AUR, though, just to measure the popularity before moving it over.
Comment by Alexander F. Rødseth (xyproto) - Monday, 28 November 2016, 23:04 GMT
I think this should be in AUR, for now. Please re-open this issue if there is new information, convincing arguments or just additional comments about this.

If an AUR package for this becomes popular enough, I'll move it to [community].

Loading...