libddwaf
sokol-tools
libddwaf | sokol-tools | |
---|---|---|
1 | 6 | |
34 | 236 | |
- | - | |
8.6 | 9.3 | |
10 days ago | 8 days ago | |
C++ | C++ | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
libddwaf
-
Go 1.21 will (likely) have a static toolchain on Linux
Even in C there can be issues. the nokigiri ruby gem builds (or used to build) libxml and libxslt (which are pure C) and has to make effort remove 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 dynamic reference to some shared libs (can't recall if it's libc.so or ld.so). 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 reference would 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)
https://github.com/DataDog/libddwaf/blob/c6a90d39d93f04ebb5e...
sokol-tools
-
QtCS2024 Compile once. Run everywhere
Yeah, their outdated crap and don't work on Windows, better use a build tool from the current century ;)
Proper build tooling still doesn't change the fact that you need to stamp out one binary per OS and CPU architecture, potentially using different compilers. This is always brittle (I would know: https://github.com/floooh/sokol-tools/actions/runs/107248810...)
-
Stop Hiding the Sharp Knives: The WebAssembly Linux Interface
I would really love being able to take any POSIX command line tool, compile that to WASI, and run it on (at least) Linux, Windows and macOS like a regular executable without having to install a separate WASI runtime.
I'm a 'WASI convert' since I was able to take an ancient 8-bit assembler written in the mid-90's (http://xi6.com/projects/asmx/), compile that as-is with the WASI SDK (https://github.com/WebAssembly/wasi-sdk), and then integrate it into a VSCode extension (https://marketplace.visualstudio.com/items?itemName=floooh.v...).
A similar problem is I have is a shader cross-compiler (https://github.com/floooh/sokol-tools) which needs to run Linux, macOS and Windows and takes too long to build locally, thus I currently need to distribute that as pre-built binaries. Compiling this to WASI works, but the filesystem access restrictions built into current wasm runtimes are a hassle to manage, and it would require a WASI runtime to be separately installed).
-
Meta Releases Intermediate Graphics Library
Sokol also provides a solution for shader cross-compilation (https://github.com/floooh/sokol-tools/blob/master/docs/sokol...), so you only need to write your shaders once no matter if you're targeting OpenGL, Metal, or DirectX.
There are other tools you could use out there with IGL, but Sokol's solution streamlines the whole process.
-
Go 1.21 will (likely) have a static toolchain on Linux
> 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 (https://github.com/floooh/sokol-tools). What potential problems should I be aware of?
-
Zig: The Modern Alternative to C
In practice it works very well though, I experimented replacing cmake with build.zig for a 'not-quite-trivial' C++ project, and tbh for cross-platform code that's a lot nicer wrestling with cmake and all the C/C++ compiler toolchain differences:
https://github.com/floooh/sokol-tools/blob/master/build.zig
-
Qb – Zero-configuration build system to quickly build C/C++ projects
Yes, here is an example:
https://github.com/floooh/sokol-tools/blob/master/build.zig
Compared to cmake, this means giving up IDE support like Xcode or Visual Studio though, it's really just a pure build system.
What are some alternatives?
gcc-static-linking
libxev - libxev is a cross-platform, high-performance event loop that provides abstractions for non-blocking IO, timers, events, and more and works on Linux (io_uring or epoll), macOS (kqueue), and Wasm + WASI. Available as both a Zig and C API.
wazero - wazero: the zero dependency WebAssembly runtime for Go developers
c - Compile and execute C "scripts" in one go!
go - The Go programming language
SFML-IGL - Rendering example with Meta's Intermediate Graphics Library and SFML
evcxr
igl - Intermediate Graphics Library (IGL) is a cross-platform library that commands the GPU. It provides a single low-level cross-platform interface on top of various graphics APIs (e.g. OpenGL, Metal and Vulkan).
qb - Zero-configuration build system to very quickly build C/C++ projects.
bash2048 - Bash implementation of 2048 game
aviary.sh - Minimal distributed configuration management in bash