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

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.




  reply	other threads:[~2006-10-08 20:44 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
2006-10-08 20:44               ` Philippe Gerum [this message]
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=1160340280.4963.28.camel@domain.hid \
    --to=rpm@xenomai.org \
    --cc=Thomas.Wiedemann@domain.hid \
    --cc=jan.kiszka@domain.hid \
    --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.