On Sun, 2006-10-08 at 21:51 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> >>
> >>  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?

No objection, but in such a case, we'd be better off moving the define
somewhere in include/posix/*.h. Gilles?

> > 
> >>  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?"

Actually, those flags went in just because I once wanted everything that
I'd build out of tree to be safe from obvious sanity issues. No
objection to allow people to relax this constraint though and get rid of
those switches from the standard flags. They are not part of the basic
pattern anyway; it's "only" about some performance/sanity trade-off.

> > 
> >>  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?

There's no downside, aside of a few bytes more in the executable's GOT.
But I agree that people using lazy binding in their apps should know
about -rdynamic and dlopen() anyway, so that part is their business
after all; we don't need to enforce it as a basic option.

> Jan

Xenomai-core mailing list

Reply via email to