Target C++ header file location rationale?
Jonathan Larmour
jifl@eCosCentric.com
Wed Jan 22 04:21:00 GMT 2003
Jonathan Larmour wrote:
> Hi all,
>
> Since the list archive is still off-line ( "Unable to read word database
> file '/sourceware/htdig/gcc/db/db.words.db'" ) I may as well ask direct...
>
> In a cross-compilation build with 3.2.1, target headers get installed in
> $(prefix)/include with target-specific additions going under the bits/
> subdir therein. What is the rationale for them living here for cross
> builds?
>
> By installing in $(prefix)/include they get mixed up with a bunch of
> host header files in a complete toolchain like, say, tcl.h (if you were
> configuring a full toolchain that included gdb and insight, say). This
> can cause confusion since that is associated with the host, and there is
> no tcl port for the target.
>
> Less relevant to me but significant is that the same applies in reverse
> - if you wanted to include that directory on the host, header files only
> really appropriate for the target could be pulled in. This could be
> relevant if this directory was ahead of others on the include path.
>
> As you know, they used to be installed in $(prefix)/$(target)/include,
> and that still makes sense.
This is, of course, completely b*llocks. I was misremembering. It's always
been like this, even for libstdc++-v2. I'd still appreciate an answer if
possible? Particularly to the question below if nothing else.
Thanks,
Jifl
> What if we configure with
> --with-gxx-include-dir=$(prefix)/$(target)/include, is there any
> potential for things to go wrong now, or in the future? Is that
> something we can use without fear?
>
> Now while in general I think it's better to go with whatever the
> defaults are, it's difficult to see why in this case, especially when
> there are disadvantages.
>
> Ta for any insights,
>
> Jifl
--
eCosCentric http://www.eCosCentric.com/ <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine
More information about the Libstdc++
mailing list