From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <452956C3.8010109@domain.hid> Date: Sun, 08 Oct 2006 21:51:31 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Xenomai-core] Compiler and linker flags References: <4528FBE5.7020803@domain.hid> <17705.6276.735921.764908@domain.hid> <45293C9B.1030608@domain.hid> <1160335881.4963.19.camel@domain.hid> In-Reply-To: <1160335881.4963.19.camel@domain.hid> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Sender: jan.kiszka@domain.hid List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: rpm@xenomai.org Cc: Thomas Wiedemann , xenomai@xenomai.org 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