This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: --with-gxx-include-dir option


Bart Veer wrote:
"Jifl" == Jonathan Larmour <jifl at eCosCentric dot 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]