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