Nov 18, 2019, 08:27 by [email protected]:

>
>
> On Friday, November 15, 2019 at 6:48:51 AM UTC+8, [email protected] 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.
>
Yes, thank you. I know how it works. I was just thinking if the linker 
namespaces would not be a better solution. But the problem with GLibC is that 
nothing younger than 15 years is considered for primetime and so there is (I 
think) only 16 possible namespaces with no ability to reuse or to insert into.

>
>
>
>> 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?
>
Because there is an executive order not to do it. Look at 
https://github.com/machinekit/machinekit-hal/blob/120c9f765cf12bcd337b66308b64b3146a26ec8d/src/rtapi/Submakefile#L165-#L180
 . So I don't want to do something which goes against basic architectural 
design of the application.

Cern.

>
>     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 > [email protected]> .
>  To view this discussion on the web visit > 
> https://groups.google.com/d/msgid/machinekit/e288af89-f67b-40c7-b435-d30406959b15%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/machinekit/e288af89-f67b-40c7-b435-d30406959b15%40googlegroups.com?utm_medium=email&utm_source=footer>>
>  .
>

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/LuLC3wf--3-1%40tuta.io.

Reply via email to