[openbeos] Re: compiler option -nostdinc
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Thu, 08 May 2003 17:22:28 +0200 CEST
Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> On Wed, 7 May 2003, Marcus Overhagen wrote:
> > > I just wanted to ask why we are using the -nostdinc option, and
> > > what's
> > > the purpose behind it.
> > I added it, the purpose was to make the whole compiling of all
> > sources independant of any headers from the host system
> > (Windows, Linux or BeOS)
Which is very nice to have, agreed.
> > > option does. It prevents the headers from the gcc tool chain to
> > > be
> > > used.
> > Why is this a bad thing? Are you sure that the headers from the
> > gcc tool chain are needed?
> As I understand it, the headers and code (libgcc.a) provided by the
> tool
> chain define/implement how the compiler deals with var args,
> exceptions,
> new and so on. If you compile code with a certain compiler, you have
> to
> use the headers/code provided by the tool chain, or otherwise risk
> broken
> binaries (if you're able to compile/link them at all).
>
> Some headers (e.g. <stdio.h>) may need to be overridden, since they
> define, how the generated code interacts with the C library -- which
> we
> are writing ourselfs -- but others should definitely not.
Exactly. BeOS has linked libroot.so statically against libgcc.a, which
means that we will always be dependent on GCC 2.95 as long as we plan
to be binary compatible with that one.
This also means we have to use the right headers that come with this
compiler. GCC 3.2 has another libgcc.a (which we wouldn't have to
statically link against libroot anymore when we switch, but that's
another issue), so it should better compile with its own headers as
well.
For plain C, the only dependency I am aware of is the varargs issue,
which has to be solved differently for each target platform. Of course,
we could add a varargs implementation for every target platform in our
repository, but I don't see the point because every compiler comes with
those includes anyway.
> > > 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.
> > You are only thinking of gcc here, why does it have it own headers
> > at all?
> > What happens if we would like to compile with openwatcom or Intel
> > compiler,
> > do they also have their own haeders?
> They actually should. Unless the system provides headers and the
> compilers
> are implemented such that they work with that headers.
I think so, too. Furthermore, I see no problem with limiting us to GCC.
It's a great compiler and available on almost every platform out there.
OTOH being able to use any other compiler available would also be nice,
but I don't think it has to be the case.
> > > Does anybody mind or have reasons to mind when I remove that?
> > I wouldn't mind, but are you sure that this is the correct way?
I think we should only provide our own headers when we want to control
a certain implementation. For C++ it's determined by the use of
libgcc.a, for plain C it probably doesn't matter, but why introduce
another solution here (I am not even sure that libgcc.a don't use the
varargs implementation)?
> > > AFAICT it doesn't have any side effects to the build on x86 (just
> > > did a
> > > full build).
> > Most likely because you build on BeOS, what happens on other
> > platforms
> > with different gcc headers?
> The right thing hopefully. :-) If you e.g. compile with gcc 3.x, I
> suspect, you'll get in trouble when using 2.x headers. I really hope,
> it
> will be no (big) problem to compile OBOS R1 with gcc 3.x (losing
> binary
> compatibility on x86 of course).
For example, I had to disable -nostdinc to be able to compile OpenBeOS
on PPC. Just because some of our headers were x86 specific where GCC's
are not.
For example, our stdarg.h included va-ppc.h for the PowerPC but
included the (simple and straightforward) x86 implementation directly.
Adios...
Axel.
Other related posts:
