Hi Pirmin,
I'm still working on the support to build libraries with Goa. [...] The current state can be found at https://github.com/trimpim/goa/tree/library_support. This still requires heavy cleanup, which I will do next year, after I have completed some of my other tasks.
thank you for the welcome update. I'm happy to see that you took my advice about the check_abi tool to heart. By casually browsing the commits, I got the impression that you had to modify it. We should keep in mind that those changes should eventually be backported to the Genode repository. I always try to keep the files shared between Genode and Goa (like the ports/mk/ content) identical between both source trees.
Yesterday I recognized an other problem, that I will have to figure out a solution for. One of the libraries that is used to build wasmedge, doesn't have a nice include directory that can be copied. The header files are located in the source directory. I will have to adapt my solution for extracting the header files.
That's an interesting point I wasn't fully aware of. In the general case, such headers may become available not before building the 3rd-party code (if they are generated by a script executed as part of the build process). So the extraction of "API artifacts" follows similar patterns as the extraction of the binaries as build artifacts.
But in contrast to build artifacts that originate from the build directory, the content of an API archive is assembled from the source directory (headers imported as plain source code), the build directory (generated headers), and the symbols directory. I'm puzzled how this assemblage could be expressed best.
I also was able to build my first library which uses autoconf/libtool to configure and build. This required (a lot) of patching in the input files thou and clearly isn't ready for prime time in the current state.
I'm in awe! Building Genode-compatible shared objects with autoconf looks like an impossible maze to me.
If the Genode tool chain had built-in heuristics regarding linker scripts and startup code following closer the lines of regular Linux tool chains, this may become easier. E.g., when calling gcc on Linux, the compiler knows where to find the libc, the libc headers, and the startup code. In contrast, with Genode's tool chain, we give explicit arguments.
Admittedly, I'm divided. On the one hand, I'd wish to remove pain points that stand in the way of porting of existing software. On the other hand, I think of builtin magic as muddy. I wonder, could that conflict in principle be solved by providing a separate tool chain - containing the libc API, etc. - for the use with Goa? Not a suggestion, merely sharing my vague thoughts about it.
Cheers Norman