FYI: Cosmopolitan for e.g. Julia portability (potentially)

Palli · May 20, 2021, 1:13am

reconfigures stock GCC and Clang to output a POSIX-approved polyglot format that runs natively on Linux + Mac + Windows + FreeBSD + OpenBSD + NetBSD + BIOS with the best possible performance and the tiniest footprint imaginable.

See at: Cosmopolitan Libc: build-anywhere run-anywhere C library

Cosmopolitan makes C a build-once run-anywhere language, similar to Java, except it doesn’t require interpreters or virtual machines be installed beforehand.
[…]
For details on how this works, please read the αcτµαlly pδrταblε εxεcµταblε blog post.

I proposed the rather cool αcτµαlly pδrταblε εxεcµταblε way back for PackageCompiler.jl, but then the issue was closed (I do not recall if Cosmopolitan existed then and what I see now claimed), and possibly Cosmopolitan, building on it, makes portable Julia now more viable if anyone feels like trying a hack to make it work.

Platform Agnostic C / C++ / FORTRAN Tooling

Who could have predicted that cross-platform native builds would be this easy? As it turns out, they’re surprisingly cheap too.

Julia could be the first portable language/binary that includes fast JIT of native code.

I’m thinking of the showstoppers, Julia is implemented by several languages, C, C++ (not STL for itself? while “LLVM makes heavy use of the C++ Standard Template Library ( STL )” and others?), FemtoLisp (should probably work) and Fortran.

This wouldn’t make Julia fully portable, to e.g. ARM and POWER, but I can live with that. And it might even be possible ARM according to the docs; or MacOS ARM emulation could work, but Julia itself could generate ARM code…?

Also Linux, means traditional ELF binaries, doesn’t imply would work on Android. That would be cool, if you first install Ubuntu on Android, which already can run Julia, potentially such (ARM) Julia build could work?

At some point there was unofficial Julia-lite, without OpenBLAS if it would help (there are also some interesting (partial) Julia replacements or also system OpenBLAS could be used), similar could be done for problematic dependencies, e.g. using Fortran, and still be useful.

It’s a bit unclear (since issue open), but it seems Python 2.7 already works this way (and other languages close, e.g. PHP):

github.com/jart/cosmopolitan

Compiling Python

opened 09:27PM - 28 Mar 21 UTC

closed 08:01PM - 19 Sep 23 UTC

ahgamut

~~https://github.com/ahgamut/python27~~ https://github.com/ahgamut/cpython/tr…ee/cosmo_py27 The `assert` macro needs to be changed in `cosmopolitan.h` to enable compilation (see #138). Afterwards, just clone the repo and run `superconfigure`. Python 2.7.18 compiled seamlessly once I figured out how `autoconf` worked, and what flags were being fed to the source files when running `make`. I'm pretty sure we can compile any C-based extensions into `python.exe` -- they just need to compiled/linked with Cosmopolitan, with necessary glue code added to the Python source. For example, I was able to compile [SQLite](https://github.com/sqlite/sqlite) into `python.exe` to enable the internal `_sqlite` module. The compiled APE is about 4.1MB with `MODE=tiny` (without any of the standard modules, the interpreter alone is around 1.6MB). Most of the modules in the stdlib compile without error. The `_socket`module (required for Python's simple HTTP server) doesn't compile, as it requires the structs from `netdb.h`. On Windows, the APE exits immediately because the intertpreter is unable to find the platform-specific files. `Module/getpath.c` and `Lib/site.py` in the Python source try to use absolute paths from the prefixes provided during compilation; Editing those files to search the right locations (possibly with some `zipos` magic) ought to fix this.

and:

github.com/jart/cosmopolitan

C++ STL Integration

opened 01:25PM - 06 Jan 21 UTC

closed 11:27PM - 21 Aug 22 UTC

nikhedonia

jovian scope

First of all, great work hacking your way to platform independence! Been just… wondering if anyone made any attempts to use it in conjunction with the c++ standard library and if so, what does work and what doesn't ? - I'd expect that the standard library depends on some platform specific code, however it would be great if I could get started somewhere so I can start refactoring those bits. I would love to package cosmopolitan for https://github.com/loopperfect/buckaroo or even built a beginner friendly SDK around this library. My naive attempt to use cosmopolitan.h in a c++ project failed with a couple errors: ``` clang++ -std=c++20 \ -I/usr/include/c++/10 \ -I/usr/include/x86_64-linux-gnu/c++/10/ \ -I/usr/include/x86_64-linux-gnu/ \ -I/usr/include \ -Io\ -g -O -static -fno-pie -mno-red-zone -nostdlib -nostdinc -U__cplusplus -o hello.com main.cpp \ -Wl,--oformat=binary -Wl,--gc-sections -Wl,-z,max-page-size=0x1000 -fuse-ld=bfd \ -Wl,-T,o/ape.lds -include o/cosmopolitan.h o/libc/crt/crt.o o/ape/ape.o o/cosmopolitan.a ``` ``` // hello.cpp #include<cosmopolitan.h> #include<vector> int main() { return 0; } ``` errors: ```bash In file included from <built-in>:1: ./o/cosmopolitan.h:284:24: error: cannot combine with previous 'int' declaration specifier typedef __WCHAR_TYPE__ wchar_t; ^ ./o/cosmopolitan.h:284:1: warning: typedef requires a name [-Wmissing-declarations] typedef __WCHAR_TYPE__ wchar_t; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./o/cosmopolitan.h:285:9: error: 'char16_t' cannot be signed or unsigned typedef __CHAR16_TYPE__ char16_t; ^ <built-in>:157:25: note: expanded from here #define __CHAR16_TYPE__ unsigned short ^ In file included from <built-in>:1: ./o/cosmopolitan.h:285:9: error: 'short char16_t' is invalid <built-in>:157:34: note: expanded from here #define __CHAR16_TYPE__ unsigned short ^ In file included from <built-in>:1: ./o/cosmopolitan.h:285:1: warning: typedef requires a name [-Wmissing-declarations] typedef __CHAR16_TYPE__ char16_t; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./o/cosmopolitan.h:286:25: error: cannot combine with previous 'int' declaration specifier typedef __CHAR32_TYPE__ char32_t; ^ ./o/cosmopolitan.h:286:1: warning: typedef requires a name [-Wmissing-declarations] typedef __CHAR32_TYPE__ char32_t; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./o/cosmopolitan.h:7712:35: error: unknown type name 'int128_t' int sleb128(const void *, size_t, int128_t); ^ ./o/cosmopolitan.h:7713:37: error: unknown type name 'int128_t' int unsleb128(const void *, size_t, int128_t *); ^ ./o/cosmopolitan.h:21493:16: error: unknown type name 'jmp_buf' void gclongjmp(jmp_buf, int) nothrow wontreturn paramsnonnull(); ^ ./o/cosmopolitan.h:21525:3: error: unknown type name 'jmp_buf' jmp_buf jb; ^ In file included from main.cpp:2: In file included from /usr/include/c++/10/vector:60: In file included from /usr/include/c++/10/bits/stl_algobase.h:60: /usr/include/c++/10/bits/functexcept.h:44:1: error: unknown type name '_GLIBCXX_BEGIN_NAMESPACE_VERSION' _GLIBCXX_BEGIN_NAMESPACE_VERSION ^ /usr/include/c++/10/bits/functexcept.h:112:1: error: unknown type name '_GLIBCXX_END_NAMESPACE_VERSION' _GLIBCXX_END_NAMESPACE_VERSION ^ /usr/include/c++/10/bits/functexcept.h:113:1: error: expected unqualified-id } // namespace ^ In file included from main.cpp:2: In file included from /usr/include/c++/10/vector:60: In file included from /usr/include/c++/10/bits/stl_algobase.h:61: /usr/include/c++/10/bits/cpp_type_traits.h:71:1: error: unknown type name '_GLIBCXX_BEGIN_NAMESPACE_VERSION' _GLIBCXX_BEGIN_NAMESPACE_VERSION ^ /usr/include/c++/10/bits/cpp_type_traits.h:214:12: error: redefinition of '__is_integer<int>' struct __is_integer<int> ^~~~~~~~~~~~~~~~~ /usr/include/c++/10/bits/cpp_type_traits.h:138:12: note: previous definition is here struct __is_integer<bool> ^ /usr/include/c++/10/bits/cpp_type_traits.h:542:5: error: unknown type name '_GLIBCXX20_CONSTEXPR' _GLIBCXX20_CONSTEXPR ^ /usr/include/c++/10/bits/cpp_type_traits.h:543:21: error: expected ';' at end of declaration inline _Iterator ^ /usr/include/c++/10/bits/cpp_type_traits.h:544:18: error: unknown type name '_Iterator' __miter_base(_Iterator __it) ^ /usr/include/c++/10/bits/cpp_type_traits.h:544:5: error: C++ requires a type specifier for all declarations __miter_base(_Iterator __it) ^ /usr/include/c++/10/bits/cpp_type_traits.h:547:1: error: unknown type name '_GLIBCXX_END_NAMESPACE_VERSION' _GLIBCXX_END_NAMESPACE_VERSION ^ /usr/include/c++/10/bits/cpp_type_traits.h:548:1: error: expected unqualified-id } // namespace ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 4 warnings and 20 errors generated. ``

Cosmopolitan works great with C++ but very little effort has been made to integrate it with an existing STL.

STL will likely be a showstopper, unless we could use system LLVM and it’s the only STL using code? At one point there was Cfront “C with classes” (later renamed C++) to C transpiler, I guess nothing similar exists anymore…

ImreSamu · May 20, 2021, 10:08pm

imho: only for the simple code …

For a complex codebase: it is not so easy to implement.
Now we have a

“Linux (Glibc)” and a “Linux (Musl)” based Julia * ( 32bit / 64 bit )
Windows (7+ / 10+ ) * ( 32bit / 64bit )
…

imho: the X86 - there is a new 4 micro-architecture feature level …
( IMHO: not the tiniest footprint including all )

> x86-64: CMOV, CMPXCHG8B, FPU, FXSR, MMX, FXSR, SCE, SSE, SSE2
> x86-64-v2: (close to Nehalem) CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3
> x86-64-v3: (close to Haswell) AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE, XSAVE
> x86-64-v4: AVX512F, AVX512BW, AVX512CD, AVX512DQ, AVX512VL

GCC 11's x86-64 Microarchitecture Feature Levels Are Ready To Roll - Phoronix

Palli · May 20, 2021, 10:43pm

Thanks for the link, I’m aware of feature levels, but wasn’t familiar with these exact terms: “x86-64-v2, x86-64-v3, and x86-64-v4”.

That doesn’t seem to be any problem. There’s not a different Julia binary (per OS) for those anyway. With a portable Julia binary across OSes, nothing changes. It (the core, not dependencies) can just target the most conservative x86-64 (and just ignore 32-bit, not a huge concern for me). At runtime when you invoke the backend, LLVM, it will generate appropriate code, for e.g. latest, even if LLVM itself is compiled for oldest. And if you want you can override just as you currently can.

You are quoting me, quoting the project “the tiniest footprint”. Yes, Julia will not be small, or smaller. That refers to the Cosmopolitan. Getting something like this working with Julia would be interesting and a first step, then making smaller might be a later step.

Palli · May 20, 2021, 10:48pm

Yes, seems not supported. You can still just use specific Julia target that or some platform Cosmopolitan doesn’t support. Musl, is not needed for Linux except for some very obscure distros like Alpine. Getting Windows, Mac and Linux most use would be awesome, and I wouldn’t rule out Musl could be supported later.

Palli · May 20, 2021, 11:10pm

The julia binary is actually only 12320 bytes. What’s taking the most space are dependencies:

-rwxr-xr-x 1 pharaldsson_sym pharaldsson_sym 184609760 mar 25 02:40 sys.so
-rwxr-xr-x 1 pharaldsson_sym pharaldsson_sym 71850032 mar 25 02:30 libLLVM-11jl.so
-rwxr-xr-x 1 pharaldsson_sym pharaldsson_sym 39025344 mar 25 02:41 libjulia-internal.so.1.6
-rwxr-xr-x 1 pharaldsson_sym pharaldsson_sym 30415776 mar 25 02:30 libopenblas64_.0.3.10.so
-rwxr-xr-x 1 pharaldsson_sym pharaldsson_sym 22521088 mar 25 02:30 libstdc++.so.6.0.26
-rwxr-xr-x 1 pharaldsson_sym pharaldsson_sym 7382888 mar 25 02:30 libgfortran.so.4.0.0
[…]

sys.so is the sysimage, and while it’s e.g. sys.dll on Windows, it’s not clear to me Cosmopolitan can’t work for such (e.g. could it be statically linked?). Worst case (for proof-of-concept), you could duplicate all dependencies, have .so and .dll, doubling in size… or tripling for MacOS too. Doesn’t sound nice, but you could also have one preferred platform, say Windows (as it’s very popular) with its DLLs, and dynamically download .so etc. on first use if you happen to run on Linux (or discover preinstalled Julia’s .so files). This likely solved potential STL issues, as they only cover libLLVM-11jl.so (or maybe more), but not the main julia or julia.exe?

ImreSamu · May 20, 2021, 11:12pm

imho: this is a default minimal Docker linux for testing .
and the docker official minimal images - based this linux.

for example postgres … has a debian(glicbc) + alpine(musl) version

for julia - it has a minimal disk savings

julia 1.6        22b56ebea464   8 days ago      486MB
julia 1.6-alpine 89e8f10e3115   3 weeks ago     408MB

Palli · May 20, 2021, 11:29pm

I’m mainly thinking of portable Julia for non-server use, to eventually support apps for end-users, and wouldn’t you then not be unlikely to use Docker?

I’ve never used it, nor had the need, I at least think it’s mainly for servers, and then you likely want to support only one infrastructure (or you can at least choose).

Linux is most used anyway for servers (even most used on Microsoft’s Azure), and I’m not too concerned about server use (current Julia binary options wouldn’t or needn’t go away). Even for Windows servers, Docker “runs on WSL 2”, so you would still use the same Julia Linux binary.