[Xenomai-core] Please remove "-I." in "xeno-config --*-cflags

[Xenomai-core] Please remove "-I." in "xeno-config --*-cflags

[Thomas Wiedemann]

Hi,

setting "-I." in the compiler flags in scripts/xeno-config.in
messes up the include file search order of the compiler,
and i can't see any good reason for it to be there. the
other flags except the xenomai include-path and the
defines are questionable, too. At least "-Wall" and
"-pipe" should be left to the programmer of the
application.

(xenomai versions 2.2.0 + 2.2.3)


Thanks,
Thomas Wiedemann

Re: [Xenomai-core] Please remove "-I." in "xeno-config --*-cflags

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

Thomas Wiedemann wrote:
> Hi,
> 
> setting "-I." in the compiler flags in scripts/xeno-config.in
> messes up the include file search order of the compiler,
> and i can't see any good reason for it to be there.

I don't see any obvious reason as well. A quick test with our software
stack revealed no problems when removing it, but we should first wait
for further input on the original reason behind it (seems to date back
into fusion times...).

BTW, providing a patch, even if it's trivial, is always welcome in such
cases.

> the
> other flags except the xenomai include-path and the
> defines are questionable, too. At least "-Wall" and
> "-pipe" should be left to the programmer of the
> application.

Well, -Wall should be considered a reasonable policy to keep code clean.
Me feeling is that this switch is fairly appropriate, specifically for
real-time applications. But it can easily be relaxed by adding specific
-Wno-xxx after the Xenomai flags. And *that* should happen explicitly.

-pipe is an optimisation of the build process, something one may
discuss, though I don't see an immediate reason why it could fail in the
context of Xenomai applications (that should use the GNU toolchain anyway).

Jan

PS: sed 's/-I.//' applied on xeno-config output may meanwhile save your
day...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] Please remove "-I." in "xeno-config --*-cflags

[Thomas Wiedemann]

[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]

> BTW, providing a patch, even if it's trivial, is always welcome in such
> cases.

I had already attached it to the email, but then i thought it was so
ridiculously small ... and removed it :)
So here it is again.

 
> Well, -Wall should be considered a reasonable policy to keep code clean.
> Me feeling is that this switch is fairly appropriate, specifically for
> real-time applications. But it can easily be relaxed by adding specific
> -Wno-xxx after the Xenomai flags. And *that* should happen explicitly.
>
> -pipe is an optimisation of the build process, something one may
> discuss, though I don't see an immediate reason why it could fail in the
> context of Xenomai applications (that should use the GNU toolchain 
anyway).

I definitley agree on the use of "-Wall" and "-pipe", but i think these
optional flags should be set in the main project, and not by external
libraries or tools. It's not that i think they would conflict with
other flags or that they are wrong or inappropriate, but just because
i expect *-config-tools to not specify any flags that affect the
compiler behaviour. I just don't want every libraries' config-script
to place the authors favorite compiler-flags into my own flags.


> PS: sed 's/-I.//' applied on xeno-config output may meanwhile save your
> day...

make's $(filter-out -I.,$(XENOMAICFLAGS)) works as well, thank you anyway 
;)

Thomas Wiedemann


[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 1262 bytes --]

diff -urN xenomai-2.2.0.orig/scripts/xeno-config.in xenomai-2.2.0/scripts/xeno-config.in
--- xenomai-2.2.0.orig/scripts/xeno-config.in	2006-06-23 11:23:24.000000000 +0200
+++ xenomai-2.2.0/scripts/xeno-config.in	2006-10-04 13:29:12.000000000 +0200
@@ -12,12 +12,12 @@
 XENO_PREFIX="${staging}${prefix}"
 XENO_CC="@CC@"
 XENO_TARGET_ARCH="@XENO_TARGET_ARCH@"
-XENO_BASE_CFLAGS="-I. -I${staging}${includedir} @XENO_USER_APP_CFLAGS@"
+XENO_BASE_CFLAGS="-I${staging}${includedir} @XENO_USER_APP_CFLAGS@"
 XENO_BASE_LDFLAGS="-L${staging}${libdir} -lpthread @XENO_USER_APP_LDFLAGS@"
-XENO_POSIX_CFLAGS="-I. -I${staging}${includedir} -I${staging}${includedir}/posix @XENO_USER_APP_CFLAGS@"
+XENO_POSIX_CFLAGS="-I${staging}${includedir} -I${staging}${includedir}/posix @XENO_USER_APP_CFLAGS@"
 XENO_POSIX_LDFLAGS="-L${staging}${libdir} -lpthread_rt -lpthread -lrt @XENO_USER_APP_LDFLAGS@"
 XENO_POSIX_WRAPPERS="${staging}${libdir}/posix.wrappers"
-XENO_UVM_CFLAGS="-I. -I${staging}${includedir} @XENO_USER_APP_CFLAGS@ -D__XENO_UVM__"
+XENO_UVM_CFLAGS="-I${staging}${includedir} @XENO_USER_APP_CFLAGS@ -D__XENO_UVM__"
 XENO_UVM_LDFLAGS="-u__xeno_skin_init -L${staging}${libdir} -luvm -lnucleus_uvm -lpthread"
 XENO_LIBRARY_DIR="${staging}${libdir}"
 
=

[Xenomai-core] Compiler and linker flags (was: Please remove "-I." in "xeno-config --*-cflags)

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2520 bytes --]

Thomas Wiedemann wrote:
>> BTW, providing a patch, even if it's trivial, is always welcome in such
>> cases.
> 
> I had already attached it to the email, but then i thought it was so
> ridiculously small ... and removed it :)
> So here it is again.

The point is if you start a thread like "[PATCH] Remove -I. from
xeno-config" and attach a full patch (including ChangeLog fragment) you
make it more likely to gain full attention and help to get it applied
quickly.

> 
>  
>> Well, -Wall should be considered a reasonable policy to keep code clean.
>> Me feeling is that this switch is fairly appropriate, specifically for
>> real-time applications. But it can easily be relaxed by adding specific
>> -Wno-xxx after the Xenomai flags. And *that* should happen explicitly.
>>
>> -pipe is an optimisation of the build process, something one may
>> discuss, though I don't see an immediate reason why it could fail in the
>> context of Xenomai applications (that should use the GNU toolchain 
> anyway).
> 
> I definitley agree on the use of "-Wall" and "-pipe", but i think these
> optional flags should be set in the main project, and not by external
> libraries or tools. It's not that i think they would conflict with
> other flags or that they are wrong or inappropriate, but just because
> i expect *-config-tools to not specify any flags that affect the
> compiler behaviour. I just don't want every libraries' config-script
> to place the authors favorite compiler-flags into my own flags.

I agree now, for the sake of cleanness and as we are not just discussing
-Wall and -pipe here:

# xeno-config --xeno-cflags
-I. -I<xenomai-inst>/include -O2 -D_GNU_SOURCE -D_REENTRANT -D__XENO__
-Wall -pipe -fstrict-aliasing -Wno-strict-aliasing

# xeno-config --posix-cflags
-I. -I<xenomai-inst>/include -I<xenomai-inst>/include/posix -O2
-D_GNU_SOURCE -D_REENTRANT -D__XENO__ -Wall -pipe -fstrict-aliasing
-Wno-strict-aliasing

# xeno-config --xeno-ldflags
-L<xenomai-inst>/lib -lpthread -rdynamic

# xeno-config --posix-ldflags
-Wl,@<xenomai-inst>/lib/posix.wrappers -L<xenomai-inst>/lib -lpthread_rt
-lpthread -lrt -rdynamic

(all x86, other platforms may vary)

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

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: [Xenomai-core] Compiler and linker flags (was: Please remove "-I." in "xeno-config --*-cflags)

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > Thomas Wiedemann wrote:
 > >> BTW, providing a patch, even if it's trivial, is always welcome in such
 > >> cases.
 > > 
 > > I had already attached it to the email, but then i thought it was so
 > > ridiculously small ... and removed it :)
 > > So here it is again.
 > 
 > The point is if you start a thread like "[PATCH] Remove -I. from
 > xeno-config" and attach a full patch (including ChangeLog fragment) you
 > make it more likely to gain full attention and help to get it applied
 > quickly.
 > 
 > > 
 > >  
 > >> Well, -Wall should be considered a reasonable policy to keep code clean.
 > >> Me feeling is that this switch is fairly appropriate, specifically for
 > >> real-time applications. But it can easily be relaxed by adding specific
 > >> -Wno-xxx after the Xenomai flags. And *that* should happen explicitly.
 > >>
 > >> -pipe is an optimisation of the build process, something one may
 > >> discuss, though I don't see an immediate reason why it could fail in the
 > >> context of Xenomai applications (that should use the GNU toolchain 
 > > anyway).
 > > 
 > > I definitley agree on the use of "-Wall" and "-pipe", but i think these
 > > optional flags should be set in the main project, and not by external
 > > libraries or tools. It's not that i think they would conflict with
 > > other flags or that they are wrong or inappropriate, but just because
 > > i expect *-config-tools to not specify any flags that affect the
 > > compiler behaviour. I just don't want every libraries' config-script
 > > to place the authors favorite compiler-flags into my own flags.
 > 
 > I agree now, for the sake of cleanness and as we are not just discussing
 > -Wall and -pipe here:
 > 
 > # xeno-config --xeno-cflags
 > -I. -I<xenomai-inst>/include -O2 -D_GNU_SOURCE -D_REENTRANT -D__XENO__
 > -Wall -pipe -fstrict-aliasing -Wno-strict-aliasing
 > 
 > # xeno-config --posix-cflags
 > -I. -I<xenomai-inst>/include -I<xenomai-inst>/include/posix -O2
 > -D_GNU_SOURCE -D_REENTRANT -D__XENO__ -Wall -pipe -fstrict-aliasing
 > -Wno-strict-aliasing
 > 
 > # xeno-config --xeno-ldflags
 > -L<xenomai-inst>/lib -lpthread -rdynamic
 > 
 > # xeno-config --posix-ldflags
 > -Wl,@<xenomai-inst>/lib/posix.wrappers -L<xenomai-inst>/lib -lpthread_rt
 > -lpthread -lrt -rdynamic
 > 
 > (all x86, other platforms may vary)
 > 
 > @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.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] Compiler and linker flags

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3468 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Thomas Wiedemann wrote:
>  > >> BTW, providing a patch, even if it's trivial, is always welcome in such
>  > >> cases.
>  > > 
>  > > I had already attached it to the email, but then i thought it was so
>  > > ridiculously small ... and removed it :)
>  > > So here it is again.
>  > 
>  > The point is if you start a thread like "[PATCH] Remove -I. from
>  > xeno-config" and attach a full patch (including ChangeLog fragment) you
>  > make it more likely to gain full attention and help to get it applied
>  > quickly.
>  > 
>  > > 
>  > >  
>  > >> Well, -Wall should be considered a reasonable policy to keep code clean.
>  > >> Me feeling is that this switch is fairly appropriate, specifically for
>  > >> real-time applications. But it can easily be relaxed by adding specific
>  > >> -Wno-xxx after the Xenomai flags. And *that* should happen explicitly.
>  > >>
>  > >> -pipe is an optimisation of the build process, something one may
>  > >> discuss, though I don't see an immediate reason why it could fail in the
>  > >> context of Xenomai applications (that should use the GNU toolchain 
>  > > anyway).
>  > > 
>  > > I definitley agree on the use of "-Wall" and "-pipe", but i think these
>  > > optional flags should be set in the main project, and not by external
>  > > libraries or tools. It's not that i think they would conflict with
>  > > other flags or that they are wrong or inappropriate, but just because
>  > > i expect *-config-tools to not specify any flags that affect the
>  > > compiler behaviour. I just don't want every libraries' config-script
>  > > to place the authors favorite compiler-flags into my own flags.
>  > 
>  > I agree now, for the sake of cleanness and as we are not just discussing
>  > -Wall and -pipe here:
>  > 
>  > # xeno-config --xeno-cflags
>  > -I. -I<xenomai-inst>/include -O2 -D_GNU_SOURCE -D_REENTRANT -D__XENO__
>  > -Wall -pipe -fstrict-aliasing -Wno-strict-aliasing
>  > 
>  > # xeno-config --posix-cflags
>  > -I. -I<xenomai-inst>/include -I<xenomai-inst>/include/posix -O2
>  > -D_GNU_SOURCE -D_REENTRANT -D__XENO__ -Wall -pipe -fstrict-aliasing
>  > -Wno-strict-aliasing
>  > 
>  > # xeno-config --xeno-ldflags
>  > -L<xenomai-inst>/lib -lpthread -rdynamic
>  > 
>  > # xeno-config --posix-ldflags
>  > -Wl,@<xenomai-inst>/lib/posix.wrappers -L<xenomai-inst>/lib -lpthread_rt
>  > -lpthread -lrt -rdynamic
>  > 
>  > (all x86, other platforms may vary)
>  > 
>  > @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__
 o -fstrict-aliasing -Wno-strict-aliasing
 o -rdynamic

Again, only /wrt to user apps. We can keep them all internally.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] Compiler and linker flags

[Philippe Gerum]

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.

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

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

> Again, only /wrt to user apps. We can keep them all internally.
> 
> Jan
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
-- 
Philippe.

Re: [Xenomai-core] Compiler and linker flags

[Jan Kiszka]

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?

Jan

Re: [Xenomai-core] Compiler and linker flags

[Philippe Gerum]

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
-- 
Philippe.

Re: [Xenomai-core] Compiler and linker flags

[Gilles Chanteperdrix]

Philippe Gerum wrote:
 > 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?

Since there are several files in include/posix and users are not
supposed to include them all, it seems easier to force the flag in
--posix-cflags.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] Compiler and linker flags

[Philippe Gerum]

On Mon, 2006-10-09 at 06:54 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>  > 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?
> 
> Since there are several files in include/posix and users are not
> supposed to include them all, it seems easier to force the flag in
> --posix-cflags.
> 

Ack. I was thinking of moving this define to a base header, but if we
really don't have any there, then let's keep it the way it is.

-- 
Philippe.