top | item 41115883

(no title)

sbstp | 1 year ago

I feel like there's a lot of potential between Go and Cosmopolitan libc. Go itself does not use libc much, as shown in the blog, but some great libraries like SQLite3 need it (unless you use https://pkg.go.dev/modernc.org/sqlite).

The ability to build a single static binary that works on Linux, Mac and Windows using Go would be life changing for the internal tools I develop at work.

discuss

order

latchkey|1 year ago

> The ability to build a single static binary that works on Linux, Mac and Windows using Go would be life changing for the internal tools I develop at work.

Just curious, life changing in what way? Obviously, 1 is better than 3, but I'm wondering if there is some other interesting reason.

fsmv|1 year ago

The same exact binary working isn't going to happen without runtime performance penalties because the syscall numbers are different on different platforms. Also I believe on windows it's not possible to avoid linking some system libraries to use windows.h stuff, there is no stable ABI.

pjmlp|1 year ago

Linux is the exception among modern OSes to have a stable syscall ABI, everyone else offers only the proper OS API as entry point into OS services.

Once upon at time, static linking was the only thing OSes were capable of, all of them moved away from that, and there is no turning back outside embedded bare metal deployments, just become some people are obsessed with static linking.

actionfromafar|1 year ago

Though msvcrt.dll has a stable subset of functions available on all Windows versions.

oguz-ismail|1 year ago

I recall reading about new Macs with ARM chips not supporting static binaries. Is it not true?

cyberax|1 year ago

All Macs don't support static binaries. That's because the syscall interface on macOS is not stable, only libc is guaranteed to be stable.