Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cosmopolitan Libc: build-once run-anywhere C library

justine.lol

Post reply on HN
Print view View original

61–70 of 171 posts

Re: Cosmopolitan Libc: build-once run-anywhere C library

#61

Post by mkup »

CyberDildonics wrote: post #9
RcouF1uZ4gsC wrote: post #5

> For an example of how that works, consider the following common fact about C which that's often overlooked. External function calls such as the following: memcpy(foo, bar, n); Are roughly equivalent to the following assembly, which leads compilers to assume that most cpu state is clobbered: I think most modern C and C++ compilers know that memcpy is special and optimize accordingly. I believe some C++ compilers rec…

Even if you are trying to avoid the standard library, visual studio will insert memcpy into a loop that is just copying memory, then the linker will error out when it can't find it.

This is true, but it's possible to prevent this behavior by turning off optimizations for just one function (by adding ``#pragma optimize("g", off)'' before the function definition and ``#pragma optimize("g", on)'' after the function definition).

Re: Cosmopolitan Libc: build-once run-anywhere C library

#62

Post by andi999 »

Can somebody explain the whole thing to me? I know how to programm on windows and linux, but thats basically at the level of calling the compiler and linker, and some parameters to sometimes build a dll. So what does this do, and how does it work? Does it apply to DLLs as well? Also, 'run anywhere' means on the same processor type?

Re: Cosmopolitan Libc: build-once run-anywhere C library

#64

Post by pwdisswordfish5 »

Cute trick, but probably fragile. It basically requires either writing functions like memcpy in assembly by hand or parsing the compiler-generated assembly post-codegen to determine the actual set of register clobbers. Otherwise it is bound to be broken as soon as the register allocator decides to clobber a different set of registers when generating the function.

Also, this effectively makes the body of the function a part of its public ABI, which makes it morally equivalent to inlining; it requires users of the function to be recompiled each time the body (and in consequence the clobber set) is changed. But since this seems to be static-linking-only library, this seems not that much of a problem in this case.

Still, I’m expecting improvements to whole-program LTO and inter-procedural optimisations to render this hack obsolete.

Re: Cosmopolitan Libc: build-once run-anywhere C library

#66

Post by rav »

jart wrote: post #60
rav wrote: post #56

I have Wine installed on my Linux system, which uses "binfmt_misc" to automatically run Windows-looking executable files through Wine. This causes an issue with Cosmopolitan, since it uses an output format that triggers binfmt_misc. I had to run this to disable binfmt_misc on my system: sudo systemctl mask proc-sys-fs-binfmt_misc.automount ...and this to disable it for just the current boot: sudo bash -c 'echo 0 > /p…

Give this a try: sudo sh -c "echo ':APE:M::MZqFpD::/bin/sh:' >/proc/sys/fs/binfmt_misc/register" That command should allow Actually Portable Executables to co-exist with WINE, which assumes the MZ prefix, since APE binaries always use the longer MZqFpD prefix.

Thanks! That worked.

I also tried adding the line to a new file /etc/binfmt.d/APE.conf, but it didn't seem to work (after a reboot); after renaming the file to zz_APE.conf, it did work after a reboot. systemd's binfmt.d registers files in alphabetical filename order, so I'm guessing it's important that /usr/lib/binfmt.d/wine.conf is registered before the APE handler, meaning its filename must be alphabetically after "wine.conf".

Re: Cosmopolitan Libc: build-once run-anywhere C library

#67

Post by mhd »

jart wrote: post #44
smcameron wrote: post #27

> Please note this is intended for people who don't care about desktop GUIs, and just want stdio and sockets [...] Not to diminish the achievement at all, but a significant limitation to be noted (and not a very surprising limitation). I also wonder about things like the sizeof(long). On 64-bit linux, this is 8, but on windows, it's 4. Well, "on windows"... maybe this throws all the APIs that make such assumptions, u…

Author here. That's not an inherent limitation. See https://justine.lol/apelife/index.html for an example of a GUI + TUI that's built using Cosmopolitan. The reason why I said what you quoted, is I'm simply trying to calibrate expectations. I don't view desktop GUIs as a productive area of focus, because there's such a lack of consensus surrounding the APIs that requires, and web browsers do a great job. As for sizeo…

Regarding consensus desktop APIs, maybe it's time to re-invent/-introduce Win32s ;)

(Although adding that to the library would add considerable bloat, and cross-platform runtime dynamic linking or a "dynamic polyfill" might be a bit beyond the scope of this)

Or raw X11 protocol, of course (WSL made X11 servers on Win10 quite common, and . If that wouldn't be so horrible, it would be interesting how small one could get basic widgets starting from scratch.

Re: Cosmopolitan Libc: build-once run-anywhere C library

#69

Post by aledthemathguy »

jart wrote: post #34
TimTheTinker wrote: post #32

This is an interesting, and potentially compelling argument that WebAssembly binaries and runtime actually aren’t the future of compile-once-run-anywhere systems software: these support syscalls, sockets, and stdin/stdout —- all of which requires platform-specific glue code to achieve using WebAssembly and standard libc (or JS).

Author here. WebAssembly has played an important role protecting CI on the Internet and it's cool that it enables us to run LLVM in the browser. I was very surprised when I learned that some people were using it offline outside of browsers, since doing so requires a JVM-like runtime such as wasmtime. Cosmopolitan proves that it's possible to just fix C instead, which might fix all the stuff that's built on top of C t…

excuse my ignorance on this, but this sounds amazing. game changing. yet it's being "served" here on ice. casually. what am I missing?

Re: Cosmopolitan Libc: build-once run-anywhere C library

#70

Post by pjmlp »

jart wrote: post #34
TimTheTinker wrote: post #32

This is an interesting, and potentially compelling argument that WebAssembly binaries and runtime actually aren’t the future of compile-once-run-anywhere systems software: these support syscalls, sockets, and stdin/stdout —- all of which requires platform-specific glue code to achieve using WebAssembly and standard libc (or JS).

Author here. WebAssembly has played an important role protecting CI on the Internet and it's cool that it enables us to run LLVM in the browser. I was very surprised when I learned that some people were using it offline outside of browsers, since doing so requires a JVM-like runtime such as wasmtime. Cosmopolitan proves that it's possible to just fix C instead, which might fix all the stuff that's built on top of C t…

> We can in fact have first-class portable native binaries, which will only require JIT compilation if they're launched on a non-x86 machine.

This is nothing new, IBM and Unisys mainframes have been doing it since the 60's.

Post reply on HN