-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: all: add GOOS=cosmo port for Cosmopolitan Libc #51900
Comments
Without looking too hard, I think this would effectively mean porting Go to a new It would be interesting to hear how much work this would be. To be clear, it is extremely unlikely that anybody on the core Go team would work on this. But if someone is interested in working on it, and can satisfy the porting policy, we could consider adding the port. |
CC @golang/release, @aclements as FYI. |
It does sound like this would be a new operating system, which somehow is the union of all existing operating systems. And what would the changes look like in the runtime? |
This proposal has been added to the active column of the proposals project |
Cosmopolitan Libc author here. Thank you for considering this proposal. Our project would love the opportunity to support the Go community. |
To answer @rsc's questions:
Try taking an existing libc integration (e.g. go/src/runtime/sys_openbsd2.go) and using that with cosmopolitan.h and cosmopolitan.a. You need to use
Cosmopolitan is the union of all operating systems in the sense that jQuery was the union of all web browsers. The only big thing we changed was we made POSIX defines symbolic. For example,
Consider using one of our pinned "amalgamation" releases. We put everything in a giant static archive. You need
Our Actually Portable Executable web server (redbean) is the no. 3 most upvoted Show HN thread in Hacker News history. See https://bestofshowhn.com/ and https://redbean.dev/ |
Given that #53383 has been accepted (clarifying our porting policy), I think that a cosmo libc port would be treated like any other secondary operating system port, and subject to the requirements there. If someone wants to start the port, you can assume GOOS=cosmo, although I don't think we'll reserve that until a port appears. Retitled issue to make clear that this is a new port, not a runtime option. There will be interesting translations necessary. The SysV ABI doesn't matter much, since it only affects C code we call on the m stacks. The variable values for things like EPERM mean that we'll have to translate to actual constants of our own choosing to preserve the constant-ness of syscall.EPERM etc on the Go side. And I assume we'd require invoking the external linker to make a binary. It's not something the Go team is going to implement ourselves, but a new port is welcome subject to the considerations in #53383, just as we would any other port. Putting this proposal on hold until someone tries to write a port. |
Placed on hold. |
@cristaloleg This proposal is on hold until somebody writes a GOOS=cosmo port. Does that exist somewhere? Thanks. |
This issue was mentioned in a Hacker News thread about GCC patching for greater portability. |
I wonder if it would be possible to use cosmocc to build with cgo, currently it hangs forever in runtime/cgo $ CGO_ENABLED=1 CC=cosmocc go build -v --ldflags '-linkmode external -extldflags=-static' main.go
runtime/cgo |
Cosmopolitan 3.0 just released |
I'm still waiting for this to be announced. Any possibilities of that happening this year? |
Now is the best time to do it. Cosmopolitan v3 was when it started to work. Cosmopolitan v4 is when it started to work well. I just published Cosmopolitan v4.0.2 twenty minutes ago which supports a larger number of open source projects, e.g. llamafile, bash, gcc, clang, qt, git, vim, emacs, links, etc. Cosmocc makes fat binaries that work great on all platforms, including Windows. Cosmopolitan has the fastest mutexes. Unlike Musl, Cosmo has a very fast string library. Lastly, Cosmo is permissively licensed ISC, MIT, BSD, and optionally Apache 2.0. |
Go is slowly becoming the de-facto lingua franca of DevOps - to the point of replacing shell scripting (see Cloudflare Blog/Using Go as a scripting language in Linux). The next great iteration would be a compile once run anywhere type of such scripting (as possible as it can be with external packaging involved). There's already a PoC libc and executable format that can run anywhere (see Cosmopolitan libc and APE). The author of Cosmpolitan and APE has indicated a willingness to collaborate and support Go running on Cosmopolitan and producing APE binaries.
The text was updated successfully, but these errors were encountered: