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