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
_______________________________________________
Genode users mailing list
[email protected]
https://lists.genode.org/listinfo/users
