using GOA to port libraries

[Duss Pirmin]

Hello Norman

On 03.01.23 14:58, Norman Feske wrote:
> Hi Pirmin,
> 
>> I'm still working on the support to build libraries with Goa.
>  > [...]

I have cleaned up the commit series.

50dc357 is a bit big for my liking, but I failed to split it up in to 
smaller, reasonable commits.

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

I agree, and will crate an issue on the main Repository that "ports 
back" the changes.

One question I have, is regarding the output format. The original writes 
to stdout. For the Goa integration I changed it to write to a file, as I 
did fail to parse the output of `abi_symbols_from_library`. I guess, the 
"native" implementation should still write to stdout in the end?
Therefore I think I will change `abi_symbols_from_library` to take a 
file descriptor as the second parameter. Do you think this is a 
reasonable approach? Os should it work in a completely different way?

[...]

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

I have now changed the extraction of headers to be taken from the build 
directory.

I had to patch some CMakeLists.txt files in my project, but in the long 
run I think, this makes the whole process much cleaner. This way the 
case of automatically generated headers (autoconf/automake) is also 
handled properly.

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

I fully agree with you, it wasn't at all a pleasing experience, 
especially compared to projects using CMake.

[...]

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

This sounds like a cool idea. But will probably be a major effort to 
undertake.

With all the changes, I'm now able to build WasmEdge which uses the 
libcxx, libcxxabi and libunwind from the LLVM project.

Cheers Pirmin