using GOA to port libraries

[Norman Feske]

Hi Pirmin,

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

Since we harmonized the binary interfaces between 32-bit and 64-bit (see 
[1]), the symbol files look almost identical. The only difference is the 
size of global data symbols that sometimes are larger on 64-bit. 
Fortunately, those symbols are rare, and the larger sizes work well for 
both 32-bit and 64-bit.

A distinction between architectures would conserve a bit of memory for 
32-bit platforms while incurring a substantial burden in terms of 
bureaucracy and maintenance. So we deliberately dropped this distinction 
for Genode.

[1] 
https://genode.org/documentation/release-notes/17.02#Genode_Application_Binary_Interface

To mitigate the risk of symbol files generated from a 32-bit .lib.so to 
be used on a 64-bit architecture, the Genode build system invokes the 
check_abi tool [2] after linking each shared library. Besides 
safety-checking the symbol sizes, the tool also performs a few other 
useful sanity checks. I think that Goa should follow these footsteps by 
invoking this tool, safeguarding the maintenance of ABIs.

[2] https://github.com/genodelabs/genode/blob/master/tool/check_abi

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

Thank you for clarifying, and congratulation for making it work!

I find it is interesting that the generated shared libraries work, which 
are - in your latest version - still linked without the genode_rel.ld 
script.

I'm not quite sure that the unconditional linkage of ld.lib.so is the 
right way to go, though. Why should a plain POSIX application or library 
depend on Genode's ABI after all?

The important part should be the linking of the 'ldso_so_support' 
library (as provided by the api/so depot archive) to .lib.so files and 
presumably the use of genode_rel.ld - essentially mirroring what 
Genode's build system does.

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

If such a warning can be added without much trouble, I'm for it. 
Mentioning this limitation in the documentation would be perfectly fine 
also.

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

Does that mean that adding depot keys via 'goa add-depot-user' does not 
work?

   goa add-depot-user <name> --depot-url <url> --pubkey-file <file>

When configuring a depot location via the 'depot_dir' configuration 
variable, this step should add the keys to the referenced depot.

I think what you are observing is that the "key ring" is initially empty 
because genode/depot/ no longer hosts any keys by default. But 
ultimately this is how it should be, doesn't it?

Regarding your commit "cmake support sub directory for cmake", have you 
considered solving this issue by placing a CMakeLists.txt file with the 
following line in your project's src/ directory?

   add_subdirectory(relative/path/to/subdirectory)

By keeping this tweak as patch inside the project's patches/ directory 
(to be applied on 'goa import'), you should be able to refer to any sub 
directory (or even multiple of them) via Goa's existing cmake support.

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