Philippe Gerum wrote:
> On Sun, 2006-10-08 at 19:59 +0200, Jan Kiszka wrote:
>>>  > @All: What flags are *really* required to build and link some *user*
>>>  > application against Xenomai? Beside that -I. at least -O2 can be fairly
>>>  > problematic I guess - if not even more. Also the debug mode of the
>>>  > Xenomai build leaks to the user if (s)he wants it or not.
>>>  > 
>>>  > Time for a cleanup?
>>> -D_GNU_SOURCE is necessary, at least when compiling for the POSIX skin,
>>> because on some platforms, it makes the defines for the pthread mutex
>>> types available.
>>> -D_REENTRANT is required when compiling a multithreaded application with
>>> the glibc. Theoretically, the glibc is not supposed to make its services
>>> thread safe when a program is not compiled with this define.
>> Ok, they will be saved from the hoover. What about those:
>>  o -D__XENO__
> POSIX code may be compiled either against the regular Linux support, or
> against the Xenomai one; this define provides a standard signature to
> test for in order to detect the second case, if need be.

Ok. Should we restrict it to --posix-cflags then?

>>  o -fstrict-aliasing -Wno-strict-aliasing
> We want strict aliasing to be enabled for optimization purpose at
> application level too, asking the compiler to silence type punned
> references in case it find somes, due to legacy code support.

So I guess the idea is just like with -Wall: prod the user to write
clean code? I'm not strictly against it, but I also understand Thomas'
argument: "what if every lib exported its private policy?"

>>  o -rdynamic
> Applications may want to use dlopen() against there own image, in which
> case, passing -rdynamic (same as --export-dynamic) makes dlsym()
> properly find global symbols exported this way by the executable.

If the only /may want/ to do this, shouldn't they apply that switch on
their own to CFLAGS? Aren't there any downsides of doing this
unconditionally via Xenomai?


Xenomai-core mailing list

Reply via email to