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.