libddwaf VS purego

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...

https://ebitengine.org/en/documents/install.html

For anything other than windows:

> Installing a C compiler

> A C compiler is required as Ebitengine uses not only Go but also C.

I mean, even on platforms without cgo, it's it working magically?

No; it's using https://github.com/ebitengine/purego, which is:

> A library for calling C functions from Go without Cgo.

Like... I mean.... okaaaay, it's not cgo, but it's basically cgo? ...but it's no cgo so you can say 'no cgo' on your banner page?

Seems kind of like... this is maybe not the right hammer for gamedev.

The other big thing we're working towards is making DarwinKit not use CGO at all! Using purego, we can call into Apple frameworks without involving CGO. This will improve build time, make smaller binaries, and allow DarwinKit to be used in programs that need to avoid CGO for whatever reason.

Click here to view the commit: https://github.com/ebitengine/purego/commit/1a4ea678b5a7598275a28e787179da1b7a058b11

Click here to view the commit: https://github.com/ebitengine/purego/commit/1a4ea678b5a7598275a28e787179da1b7a058b11

Maybe interesting for you: https://github.com/ebitengine/purego

most X11 functionality can be accessed via xgb|xgbutil (jezek has a current fork). nucular makes use of it via shiny. OpenGL and such libraries can be assumed to exist on those systems, so directly calling those c libraries without cgo is a possibility. Ebiten is currently working on it: purego.

In the malware reverse engineering scene, there are a lot of forks of the upstream "debug" go library, because it allows loading, parsing, compiling and executing libraries from disk (rather than in-kernel or in-userspace).

And there's also "purego" as an implementation that directly generates shellcode.

Maybe those will help you, too?

I am just mentioning these because for my use cases those approaches worked perfectly, CGO free.

[1] https://github.com/Binject/debug

[2] https://github.com/ebitengine/purego