On Friday, November 15, 2019 at 6:48:51 AM UTC+8, ce...@tuta.io wrote:
>
> Hello,
> recently, in my play, I ran afoul of the Machinekit-HAL symbol visibility
> mechanism, where the RTAPI symbols must be post-processed in the output ELF
> by comparing sections and deleting symbols not defined as an EXPORT_SYMBOL
> and also the explicit denial of rtapi_app being linked as a
> -export-dynamic.
>
> (Point: I presume that the userspace RT threads focus is design feature of
> Machinekit. Not something which happened in the passing.)
> I plus/minus do get why the symbol isolation is needed. But why was this
> form used over own linker namespaces with run-time exported symbols to few
> important functions?
>
This is actually a relic of the days of kernel threads and integrating with
Linux KBUILD. Hopefully that's enough of a clue to track down your
problem, since I've forgotten almost everything else about it.
And how to best "export" few symbols from rtapi_app to other modules given
> that rtapi_app cannot export any symbols? The best thing I came up with is
> to create shared library which will be linked both by rtapi_app and given
> module, given the fact that all live in one linker namespace.
>
>
Well, `rtapi_app` CAN export symbols, those marked with `EXPORT_SYMBOL`.
To export a few symbols, that's the "best way" because it exists, it works,
and other developers are familiar with it. Why won't it work in your use
case?
John
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github:
https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/machinekit/e288af89-f67b-40c7-b435-d30406959b15%40googlegroups.com.
