3 ms·

> but that is only for software written in C, it does not work with C++. I have a pretty complex C++ command line tool which works just fine with MUSL and resu

> but that is only for software written in C, it does not work with C++. I have a pretty complex C++ command line tool which works just fine with MUSL and results in a distro-agnostic executable (https://github.com/floooh/sokol-tools https://github.com/floooh/sokol-tools). What potential problems should I be aware of?

lloeki 4y ago
Even in C there can be issues. the nokigiri ruby gem builds (or used to build) libxml and libxslt (which are pure C) with patches making effort in removing a couple of GNUisms. For C++ we were faced with some issues, so the process we ended up with is: - build musl, install it in some location - inject a few GCC libs and linux headers required for C runtime to have the above location be a proper sysroot for clang to use - build LLVM libc++ and a few libs (e.g libunwind) as static libs against that sysroot using clang, and inject them into the sysroot - build whatever C++ final product we want against the sysroot using clang, statically linking libc++ in - for a dynamic lib, remove " "needed" dynamic reference to libc.so in ELF. also, hide all symbols from libc++ and load with bind local so that when loaded the shared lib prefers its internal symbols (which would make it crash if it jumps to another libc++) and does not pollute the symbol namespace with its internal ones (which would make another lib crash if it jumps to the internal libc++) - for an executable binary instead of a lib, dynamic references may instead need to be altered so that it works for both It all hinges on musl being a subset of glibc, which is not entirely true either (see the musl website for differences in behaviour, which may or may not matter depending on the piece of software) See: https://wiki.musl-libc.org/functional-differences-from-glibc.html https://wiki.musl-libc.org/functional-differences-from-glibc... https://github.com/DataDog/libddwaf/blob/c6a90d39d93f04ebb5e92c6a891b3c99db018893/docker/libddwaf/README.md#portable-libddwaf-on-any-linux-26 https://github.com/DataDog/libddwaf/blob/c6a90d39d93f04ebb5e...

lloeki 4y ago

Even in C there can be issues. the nokigiri ruby gem builds (or used to build) libxml and libxslt (which are pure C) with patches making effort in removing a couple of GNUisms. For C++ we were faced with some issues, so the process we ended up with is: - build musl, install it in some location - inject a few GCC libs and linux headers required for C runtime to have the above location be a proper sysroot for clang to use - build LLVM libc++ and a few libs (e.g libunwind) as static libs against that sysroot using clang, and inject them into the sysroot - build whatever C++ final product we want against the sysroot using clang, statically linking libc++ in - for a dynamic lib, remove " "needed" dynamic reference to libc.so in ELF. also, hide all symbols from libc++ and load with bind local so that when loaded the shared lib prefers its internal symbols (which would make it crash if it jumps to another libc++) and does not pollute the symbol namespace with its internal ones (which would make another lib crash if it jumps to the internal libc++) - for an executable binary instead of a lib, dynamic references may instead need to be altered so that it works for both It all hinges on musl being a subset of glibc, which is not entirely true either (see the musl website for differences in behaviour, which may or may not matter depending on the piece of software) See: https://wiki.musl-libc.org/functional-differences-from-glibc.html https://wiki.musl-libc.org/functional-differences-from-glibc... https://github.com/DataDog/libddwaf/blob/c6a90d39d93f04ebb5e92c6a891b3c99db018893/docker/libddwaf/README.md#portable-libddwaf-on-any-linux-26 https://github.com/DataDog/libddwaf/blob/c6a90d39d93f04ebb5e...