All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@domain.hid>
To: rpm@xenomai.org
Cc: Thomas Wiedemann <Thomas.Wiedemann@domain.hid>, xenomai@xenomai.org
Subject: Re: [Xenomai-core] Compiler and linker flags
Date: Sun, 08 Oct 2006 21:51:31 +0200	[thread overview]
Message-ID: <452956C3.8010109@domain.hid> (raw)
In-Reply-To: <1160335881.4963.19.camel@domain.hid>

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


  reply	other threads:[~2006-10-08 19:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-04 12:07 [Xenomai-core] Please remove "-I." in "xeno-config --*-cflags Thomas Wiedemann
2006-10-04 13:11 ` Jan Kiszka
2006-10-04 14:23   ` Thomas Wiedemann
2006-10-08 13:23     ` [Xenomai-core] Compiler and linker flags (was: Please remove "-I." in "xeno-config --*-cflags) Jan Kiszka
2006-10-08 15:25       ` Gilles Chanteperdrix
2006-10-08 17:59         ` [Xenomai-core] Compiler and linker flags Jan Kiszka
2006-10-08 19:31           ` Philippe Gerum
2006-10-08 19:51             ` Jan Kiszka [this message]
2006-10-08 20:44               ` Philippe Gerum
2006-10-09  4:54                 ` Gilles Chanteperdrix
2006-10-09  6:57                   ` Philippe Gerum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=452956C3.8010109@domain.hid \
    --to=jan.kiszka@domain.hid \
    --cc=Thomas.Wiedemann@domain.hid \
    --cc=rpm@xenomai.org \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.