Hello Norman
On 03.01.23 14:58, Norman Feske wrote:
Hi Pirmin,
I'm still working on the support to build libraries with Goa.
> [...]
I have cleaned up the commit series.
50dc357 is a bit big for my liking, but I failed to split it up in to
smaller, reasonable commits.
The current state can be found at
https://github.com/trimpim/goa/tree/library_support. This still
requires heavy cleanup, which I will do next year, after I have
completed some of my other tasks.
thank you for the welcome update. I'm happy to see that you took my
advice about the check_abi tool to heart. By casually browsing the
commits, I got the impression that you had to modify it. We should keep
in mind that those changes should eventually be backported to the Genode
repository. I always try to keep the files shared between Genode and Goa
(like the ports/mk/ content) identical between both source trees.
I agree, and will crate an issue on the main Repository that "ports
back" the changes.
One question I have, is regarding the output format. The original writes
to stdout. For the Goa integration I changed it to write to a file, as I
did fail to parse the output of `abi_symbols_from_library`. I guess, the
"native" implementation should still write to stdout in the end?
Therefore I think I will change `abi_symbols_from_library` to take a
file descriptor as the second parameter. Do you think this is a
reasonable approach? Os should it work in a completely different way?
[...]
That's an interesting point I wasn't fully aware of. In the general
case, such headers may become available not before building the
3rd-party code (if they are generated by a script executed as part of
the build process). So the extraction of "API artifacts" follows similar
patterns as the extraction of the binaries as build artifacts.
I have now changed the extraction of headers to be taken from the build
directory.
I had to patch some CMakeLists.txt files in my project, but in the long
run I think, this makes the whole process much cleaner. This way the
case of automatically generated headers (autoconf/automake) is also
handled properly.
I also was able to build my first library which uses autoconf/libtool
to configure and build. This required (a lot) of patching in the input
files thou and clearly isn't ready for prime time in the current state.
I'm in awe! Building Genode-compatible shared objects with autoconf
looks like an impossible maze to me.
I fully agree with you, it wasn't at all a pleasing experience,
especially compared to projects using CMake.
[...]
Admittedly, I'm divided. On the one hand, I'd wish to remove pain points
that stand in the way of porting of existing software. On the other
hand, I think of builtin magic as muddy. I wonder, could that conflict
in principle be solved by providing a separate tool chain - containing
the libc API, etc. - for the use with Goa? Not a suggestion, merely
sharing my vague thoughts about it.
This sounds like a cool idea. But will probably be a major effort to
undertake.
With all the changes, I'm now able to build WasmEdge which uses the
libcxx, libcxxabi and libunwind from the LLVM project.
Cheers Pirmin
_______________________________________________
Genode users mailing list
[email protected]
https://lists.genode.org/listinfo/users
