Hello Norman
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
Thanks for the directional explanation, I will also integrate the `check_abi` tool.
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.
Thanks for explaining these internals. Using the Genode build system I never had to think about these things.
I will adapt my changes to take everything mentioned above in to account.
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.
Looking at the code, I think, the only place where the warning can easily be added, is when extracting the library symbols. Everywhere else it isn't clear if a library, a binary or both are built.
Adding the information to the documentation is definitively really important. I'll do that.
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?
As I used the shared depot, I thought that I could skip over this step. But I agree with your explanation, and the general work-flow.
What do you think about adding the possibility to copy the files from a sculpt directory the user already uses for "normal" Genode work?
goa add-depot-user <name> --sculpt-path <path/to/sculpt>
When used like that, there would probably no need to reset the depot directory. That way one could save some time recompiling artifacts already existing.
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.
As I do not really know CMake, I didn't think of that. With a few more lines added this works. Therefore this patch will no longer be included.
Regards, Pirmin