Cosmopolitan Libc: build-once run-anywhere C library
1–10 of 171 posts
Re: Cosmopolitan Libc: build-once run-anywhere C library
#2I'm a huge fan of the ideas behind this library. Using the stable ABI of "magic numbers" is brilliant. Would love to see this solution gain more usage!
Re: Cosmopolitan Libc: build-once run-anywhere C library
#3It appears to build a "naked" thompson shell script without a shebang line that works as a PE file for Windows/DOS, and uses `exec` to feed a binary to the shell via a pipe.
Interesting approach for a universal binary.
Re: Cosmopolitan Libc: build-once run-anywhere C library
#4Sorry for being naive, but how can it be possible that nobody had thought of this approach and this approach would have actually worked? What have been preventing people from coming up with something like this?
Re: Cosmopolitan Libc: build-once run-anywhere C library
#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 recognize when you are using memcpy just to do bit casting to different representations and avoid doing a memory copy at all.
Re: Cosmopolitan Libc: build-once run-anywhere C library
#6Sorry for being naive, but how can it be possible that nobody had thought of this approach and this approach would have actually worked? What have been preventing people from coming up with something like this?
I think it's been pondered a bunch, but the legwork required to build the headers for each system so that you can execute the same binaries on every platform was tough.
Re: Cosmopolitan Libc: build-once run-anywhere C library
#7Sorry for being naive, but how can it be possible that nobody had thought of this approach and this approach would have actually worked? What have been preventing people from coming up with something like this?
I can think of two reasons: It's arguably a hack and it's not needed.
While this is awesome, it can easily break (zsh already seems to do so) and, as the author states, it is not meant for GUI apps or programs relying deeply on OS APIs, which includes a lot of apps.
Additionaly, it does not solve an important problem. Doing a build for each supported OS is not that hard and easily automated. The actual problem is to be able to reuse code and this is solved for the most part.
Re: Cosmopolitan Libc: build-once run-anywhere C library
#8wow, most likely, this means there would be a virus infective to all operating systems...
Re: Cosmopolitan Libc: build-once run-anywhere C library
#9> 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.
Re: Cosmopolitan Libc: build-once run-anywhere C library
#10Sorry for being naive, but how can it be possible that nobody had thought of this approach and this approach would have actually worked? What have been preventing people from coming up with something like this?
Not an answer, but Splunk currently has a large deployment of a C++ application that supports a large variety of platforms. At least as of a few years ago, they deployed C++ indexing and querying nodes on customer machines. They've spent a great deal of time to accommodate the peculiarities of enterprise customers, old compilers, etc. One might imagine that a "build once run anywhere" platform would benefit them, but they've found a business model where they were able to work around the peculiarities and still be profitable.
So while there's probably some interesting historical reasons that explain why there's no "JVM for C++", Splunk is a good example of a modern technical / business model where conquering platform fragmentation was feasible.