This is one of the most interesting projects I have seen this year. Congratulations for the idea and for the execution.
This is such a nicer compliment than it will be in a week.
Cosmopolitan Libc: build-once run-anywhere C library
101–110 of 171 posts
Re: Cosmopolitan Libc: build-once run-anywhere C library
#102Earlier quoted context omitted.
Author here. Here's the best explanation I've thought of so far: > If it's this easy, why has no one done this before? The best answer I can tell is it requires an minor ABI change, where C preprocessor macros relating to system interfaces need to be symbolic. This is barely an issue, except in cases like switch(errno){case EINVAL:...}. https://justine.lol/ape.html It also took an act of willpower. This is a novel ap…
Have you tried to code-sign executables produced by this method?
On macOS, these executables can be signed with a detached signature. Surprisingly, the embedded codesignature also works (but the signature is stored in an extended attribute on the filesystem).
Re: Cosmopolitan Libc: build-once run-anywhere C library
#103Earlier quoted context omitted.
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…
If Sun would have picked a ‘real’ CPU, I doubt it would have been x86 (did they even sell any of them at the time?) Also, picking a real CPU is only worth it for running on that CPU, and that particular one. If they had picked x86 in 1996, they wouldn’t even have supported MMX. In a platform-independent design, using n registers in the virtual CPU is only a good idea for n = 0 (i.e. a stack machine, as in the JVM, .N…
Also, the high-level nature of Java bytecode enables/simplifies many optimisations in the JIT.
For example, dynamic dispatch is handled by the JIT, it's not encoded into low-level Java bytecode instructions, so if the JIT can see there's only one class loaded that implements a certain interface, it can generate code that directly invokes methods of that implementing class, without going through a vtable. It can do this even across library boundaries. That wouldn't be possible (or at least, would be greatly complicated) if Java bytecode provided pre-baked machine code.
Modern JVMs also have pretty deep integration of the GC and the JIT, if I understand correctly. The Java bytecode format is high level so the JIT is quite free to implement memory-management however it likes. If the JVM took a truly low-level approach to its IR, we'd presumably be stuck with 90's GC technology.
I imagine it would also have implications for the way the JVM handles concurrency. It seems right that it defines its own memory model with its own safety guarantees, rather than defining its model as whatever x86 does.
It's telling that .Net took the same high-level approach that Java bytecode did.
Re: Cosmopolitan Libc: build-once run-anywhere C library
#104Earlier quoted context omitted.
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).
A better way to do with with GCC at least is -fno-builtin.
You can disable them individually too: -fno-builtin-memcpy
Re: Cosmopolitan Libc: build-once run-anywhere C library
#105This is what I've been working on with RISC-V, and you have no idea how much resistance I get when I try to fix the problems relating to calling conventions, inline assembly and system calls. I don't want to have to explain what I'm doing from the beginning every time I have a complex question about how to make a function call from inline assembly. It has really turned me off from stackoverflow as a whole. Sorry for…
I reached the same conclusion about stackoverflow.
Is there an incentive from the real world to answer questions because so many beginner try it?
Re: Cosmopolitan Libc: build-once run-anywhere C library
#106This is what I've been working on with RISC-V, and you have no idea how much resistance I get when I try to fix the problems relating to calling conventions, inline assembly and system calls. I don't want to have to explain what I'm doing from the beginning every time I have a complex question about how to make a function call from inline assembly. It has really turned me off from stackoverflow as a whole. Sorry for…
I have the same experience. Stack Overflow is not great when you try to achive something novel or do something new from scratch.
Re: Cosmopolitan Libc: build-once run-anywhere C library
#107"Run anywhere" appears several times in the page, but it seems to be a wild exaggeration, especially given the comparison to Java.
Considering that for Java it really means "run anywhere you have a JVM/JRE already installed", the marketing slogan is an exaggeration in both cases.
Re: Cosmopolitan Libc: build-once run-anywhere C library
#108Earlier quoted context omitted.
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 ge…
It should be possible to compile wxWidgets with Cosmopolitan, one variant per platform (win32, POSIX/X11, MacOS) and initialise the correct one at runtime depending on where you're launched, no?
Re: Cosmopolitan Libc: build-once run-anywhere C library
#109This is what I've been working on with RISC-V, and you have no idea how much resistance I get when I try to fix the problems relating to calling conventions, inline assembly and system calls. I don't want to have to explain what I'm doing from the beginning every time I have a complex question about how to make a function call from inline assembly. It has really turned me off from stackoverflow as a whole. Sorry for…
I have the same experience. Stack Overflow is not great when you try to achive something novel or do something new from scratch.
Can you guys link to an example?