using GOA to port libraries

[Norman Feske]

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

-- 
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth