[ECOS] --with-gxx-include-dir option

Jonathan Larmour jifl@eCosCentric.com
Tue Mar 25 11:44:00 GMT 2003


Bart Veer wrote:
>>>>>>"Jifl" == Jonathan Larmour <jifl@eCosCentric.com> writes:
> 
> 
>     Jifl> Bart Veer wrote:
>     >> Now for the not so short answer. This configuration option
>     >> controls where the C++ header files like <new> get installed.
>     >> The default location is in $(PREFIX)/include. That is fine for
>     >> building a native toolchain. For building a cross-compiler it
>     >> is not quite right $(PREFIX)/include is for host-side header
>     >> files, and <new> is a target-side header file.
> 
>     Jifl> We've been through this before elsewhere - I'm afraid I
>     Jifl> think you somewhat misunderstand the intention and purpose
>     Jifl> of what the GCC C++ guys have arranged.
> 
> No, I understand exactly what the g++ guys have done. I just don't
> agree with it.

Then persuade them to change it if you think it's right. However, down the 
road when we start using the C++ headers in earnest, I am *not* going to 
be happy about a situation where bugs are reported to the libstdc++ 
maintainers and the -v output will show an include path that is contrary 
to the libstdc++ maintainers' policy. People may, rightly or wrongly, 
point fingers at that first.

 > Also I don't believe there are any real problems with
> --with-gxx-include-dir since I have now built quite a few toolchains
> using that option and there has not been a single reported SEGV with
> those builds.

In your environment, with the particular sources you used.

But *everyone else* builds with the default include dir setting with no 
problems, and that's what is tested everywhere else.

To be absolutely clear: what problem are you trying to solve?

The single most trivial "advantage" is that when trimming the install tree 
you can go rm -r include rather than rm include/*.

> Further, I doubt that specifying --with-gxx-include-dir is the real
> cause of the SEGV in the build that was originally reported. More
> likely there is some other bug in the compiler that is now being
> triggered because e.g. the length of some built-in string is different
> and hence some other data is now differently aligned.

I agree it's entirely possible, although you would get the same effect 
with different lengths of built-in paths too, since those will be stored 
internally too.

Put it like this, if you had to report this problem to the G++ people now, 
don't you think they would tell you to stop using --with-gxx-include-dir 
first? While it's being used, there will always be doubt.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss



More information about the Ecos-discuss mailing list