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