[openbeos] Re: compiler option -nostdinc
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Mon, 05 May 2003 21:33:07 +0200 CEST
"Tony" <togermano@xxxxxxxxx> wrote:
> sex
Fascinating idea, it doesn't help with the issue at hand though. ;-)
> ----- Original Message -----
> From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
> To: <openbeos@xxxxxxxxxxxxx>
> Sent: Monday, May 05, 2003 2:12 PM
> Subject: [openbeos] Re: compiler option -nostdinc
>
>
> > Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > > > I just wanted to ask why we are using the -nostdinc option, and
> > > > what's
> > > > the purpose behind it.
> > > > I think we initially used it to prevent gcc from including the
> > > > Be
> > > > headers - but (as we already found out long ago) that's not
> > > > what
> > > > this
> > > > option does.
> > > Did we? At least I believed until now, that it indeed causes the
> > > standard include paths to be omitted.
> >
> > At least I did, but that was apparently not really correct ;-))
> > I just tried, and it obviously removes all built-in headers.
> > Anyway,
> > our specified headers have a higher priority and will be taken
> > before
> > any others will be used.
> >
> > > > It prevents the headers from the gcc tool chain to be used.
> > > Such as <new>? But it apparently works -- you use it in BFS,
> > > don't
> > > you?
> >
> > We have a <new> in our repository, that's why it does work.
Oh, I see. Well, it doesn't belong there.
> > > > And while we are able to build OpenBeOS with this option on the
> > > > x86
> > > > platform, I cannot see a reason why we would like to replace
> > > > the
> > > > gcc
> > > > headers with our own; AFAICT there is no advantage, but it
> > > > causes
> > > > trouble when trying to build it on other platforms.
> > > > Does anybody mind or have reasons to mind when I remove that?
> > > >
> > > > AFAICT it doesn't have any side effects to the build on x86
> > > > (just
> > > > did a
> > > > full build).
> > > If the option does, what I suspected it to do, then I find that
> > > it
> > > makes
> > > very much sense, since we certainly want our build to depend as
> > > little as
> > > possible on the build platform -- ideally we could build on any
> > > system
> > > (any system with gcc maybe).
> >
> > Indeed, that's exactly the point: it doesn't build on other
> > platforms,
> > because some platform dependent headers are missing (such as <va-
> > ppc.h>
> > which is the PowerPC varargs header, included in stdarg.h).
> > Now, we could either a) add the missing headers for each platform,
> > or
> > b) rely on the tool chain to provide them.
> > I am strongly tending towards b) - but I think the best way to
> > achieve
> > this would probably be to use the -nostdinc option, and add the
> > tool
> > chain includes later on as well.
I'd favor this approach.
> > The header includes could be determined by the configure script.
> > Although I currently don't know where this information is taken
> > from
> > (we could use platform defaults, though...).
> > What are you thinking?
We're already getting the directory of libgcc.a in the configure
script. I don't know, whether that's true for all GCC versions, but at
least the ones I saw have their headers in the `include' subdirectory.
So, things shouldn't be that difficult.
> > > > BTW there seems to be a build problem: the objects for all kits
> > > > are
> > > > located in the same directory (which might turn out as annoying
> > > > someday
> > > > :-).
> > > The objects for libopenbeos (i.e. App, Interface and Storage Kit)
> > > aren't
> > > created in the subdirectories, since the library is built there.
> > > I
> > > think,
> > > it should be possible to change this behavior, I just didn't take
> > > the
> > > time
> > > to do it.
> >
> > Okay, well, we can also just solve it when there actually is a
> > problem.
My favorite strategy: Ignore it as long as possible. ;-)
CU, Ingo
Other related posts:
