Re: [Xenomai] Default options in the debian package

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 04/20/2013 05:18 PM, Jan Kiszka wrote:

> On 2013-04-20 17:14, Gilles Chanteperdrix wrote:
>> On 04/20/2013 10:19 AM, Jan Kiszka wrote:
>>
>>> On 2013-04-20 08:04, Michael Haberler wrote:
>>>>
>>>> Am 19.04.2013 um 21:06 schrieb Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
>>>>
>>>>> On 04/19/2013 01:46 PM, Leopold Palomo-Avellaneda wrote:
>>>>>
>>>>>> [1] 
>>>>>> http://lists.mech.kuleuven.be/pipermail/orocos-users/2013-April/006986.html
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> that link does not tell us why you need this option. And that would be
>>>>> the most important information.
>>>>
>>>> with the linuxcnc package build I need to turn on --enable-dlopen-skins as well to get Python modules to work properly
>>>
>>> OK, it looks like we should try harder to detect dlopen scenarios during
>>> runtime to avoid build-time switches. This is likely Xenomai 3 material:
>>>
>>>  - We need to disable TLS optimizations by default (no big deal).
>>>
>>>  - In the POSIX skin constructor, we need to read out the mlockall
>>>    state, lock everything if necessary, and restore the state
>>>    accordingly afterward. The Nucleus may help us here if there is no
>>>    adequate libc service (ABI change -> Xenomai 3).
>>>
>>>  - IIRC, the problem with unconditional auto-shadowing back then were
>>>    the improper scheduling parameters that POSIX used to apply. That
>>>    was fixed a while back. So if we simple re-apply the current
>>>    parameters, it should cause no harm in a dlopen scenario. But I need
>>>    to check this again at work against our scenario.
>>
>>
>> You do not like the idea of an environment variable allowing to disable
>> the automatic shadowing?
> 
> Not as a long-term solution as it is user-unfriendly. But it can be an
> option worth considering for 2.6.


Apparently -forge is already doing it. The advantage of this solution is
that the same binary serves well several usages, if we intend to provide
packages as generic as possible, this seems like the way to go. Several
of the changes I made in the last few weeks go in the same direction.


-- 
                                                                Gilles.