using GOA to port libraries

[Duss Pirmin]

Hello Norman

On 24.11.22 11:52, Norman Feske wrote:
> Hi Pirmin,
> 
>> I have now a first version of Goa that supports creation of libraries.
>  >
>  > [...]
>  >
>  > [1] https://github.com/trimpim/goa/tree/library_support
> 
> thank you for sharing your work, which looks very promising.

Thanks for the kind words.

> The following thoughts crossed my mind when looking through the commits 
> of your branch.
> 
> - It is very good to see how you followed Goa's internal patterns,
>    even down to the documentation. :)
> 
>    Down the road, it would be good to avoid the code repetitions
>    in 'extract_api_artifacts'. From cursory look, there seem to be
>    many similarities with the existing 'extract_artifacts_from_build_dir'
>    function. So it may be worth factoring out the reusable parts of
>    the existing code into small utility functions as an intermediate
>    commit.

I agree with you. I had this on my radar already, but wanted to know the 
differences between the different uses of such a utility function first. 
I will create such a commit.

> - The ABI (in the form of the symbols file) should better not be
>    implicitely created from the linked library. A manual curation
>    step should remain part of the work flow. The (manual) invocation
>    of the abi_symbols utility (e.g., disguised as a goa command) can
>    possibly streamline this step (see below) but it should not
>    transparent.
> 
>    The main reason is that the symbol sizes are sometimes critical.
>    A symbol file created via the abi_symbols tool from a 32-bit .lib.so
>    file won't always work on 64-bit architectures. A secondary reason
>    is that an ABI is sometimes only a subset of the symbols found in
>    an .lib.so file. Removing symbol noise is good for keeping the ABI
>    stable over time. The subset can be best carved out by manual
>    inspection.
> 
>    Hence, the symbols files should be handled as part of the Goa
>    project, not generated automatically. To do so, we'd need a
>    convention, e.g., hosting symbol files always in project-local
>    files called 'symbols/<libname>' in the project directory.
>    The name of the <libname> would correspond to the base name of
>    the .lib.so file. With such a convention in place, Goa could
>    aid the update/extraction of symbols via a command like:
> 
>       goa extract-abi-symbols

I see your point on this, and will change the process accordingly.

Should I also support something like 'symbols/<arch>/<libname>' for 
libraries that need different symbol files per platform?

> - I was surprised to find Genode's linker script [2] genode_rel.ld
>    absent from your commit series. Do the resulting shared libraries
>    actually work with Genode's dynamic linker? I wouldn't have expected
>    that.

When I fist tried to build a library for the `arm_v8a` platform, I 
noticed this and other errors that were in the library part.

With my latest commit (pushed just after receiving your mail), I fixed that.
I can now run a the test program of the `spdlog` library on x86 using 
the library created with Goa [1].

This is currently only tested with cmake libraries, as I do not have any 
qmake of autoconf to test this with. Should I add a warning / error if 
somebody tries to use the library feature in the untested cases?

I added an other commit that uses the depot_user for the archives when 
building the Linux run environment.

When using the depot directory of my Genode source tree, I noticed one 
minor "annoyance" now that the `pubkey` and `download` files have moved 
to a different location, Goa doesn't find them and complains. If you 
wont mind, I will add an option to specify the location(s) of the depot 
users.


[1] https://github.com/trimpim/wasmedge-genode/tree/spdlog_library

Cheers
Pirmin