[openbeos] Re: compiler option -nostdinc
- From: "Tony" <togermano@xxxxxxxxx>
- To: <openbeos@xxxxxxxxxxxxx>
- Date: Mon, 5 May 2003 20:26:01 -0400
sex is good
----- Original Message -----
From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
To: <openbeos@xxxxxxxxxxxxx>
Sent: Monday, May 05, 2003 3:33 PM
Subject: [openbeos] Re: compiler option -nostdinc
> "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:
