using GOA to port libraries

[Pirmin Duss]

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