public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug preprocessor/48957] New: GCC's handling of include-fixed does not work well with --sysroot
@ 2011-05-11 4:54 psmith at gnu dot org
2011-05-11 10:28 ` [Bug preprocessor/48957] " joseph at codesourcery dot com
0 siblings, 1 reply; 2+ messages in thread
From: psmith at gnu dot org @ 2011-05-11 4:54 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48957
Summary: GCC's handling of include-fixed does not work well
with --sysroot
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: psmith@gnu.org
When GCC builds, it creates and stows away internally an "include-fixed"
directory containing "fixed-up" versions of the system headers files on the
system it was built with. This feels wrong to me: it gives GCC a hard
dependency on the specific set of system header files present when GCC was
built. It's potentially incorrect even for straightforward installations,
where a newer header file provided with a package upgrade might be ignored in
preference to an older "fixed" version. However, when attempting to create a
relocatable version of GCC it's even more problematic.
In particular, it seems very wrong (and, in fact, it often doesn't work) to
search the include-fixed directory when the user has specified a --sysroot
flag, choosing to compile against a wholly different set of headers and
libraries than the ones on the host system.
I think that the include-fixed directory should be associated with the sysroot,
somehow, not embedded deeply into the compiler internals, and when --sysroot is
provided there should be a well-known location inside the sysroot which will be
searched for include-fixed headers.
Also, the fixinc.sh script should be better documented and enhanced to be
simpler to run, so that it can be invoked more easily against a given sysroot
to construct the include-fixed directory for that sysroot.
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug preprocessor/48957] GCC's handling of include-fixed does not work well with --sysroot
2011-05-11 4:54 [Bug preprocessor/48957] New: GCC's handling of include-fixed does not work well with --sysroot psmith at gnu dot org
@ 2011-05-11 10:28 ` joseph at codesourcery dot com
0 siblings, 0 replies; 2+ messages in thread
From: joseph at codesourcery dot com @ 2011-05-11 10:28 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48957
--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-05-11 10:16:53 UTC ---
On Wed, 11 May 2011, psmith at gnu dot org wrote:
> I think that the include-fixed directory should be associated with the sysroot,
It should be associated with each system include directory (sysroot or
otherwise) - so there should be a fixed version of /usr/local/include,
searched immediately before /usr/local/include, and likewise for
/usr/include. But there are certainly sysroot uses where include-fixed is
still relevant - where the sysroot is based on a copy of that used when
GCC was built, but with extra libraries added. (That's the case of
sysroots that works most reliably for other reasons as well; GCC's runtime
libraries get configured depending on the libc libraries and headers
present when GCC was built, and in some cases the headers affect the
configuration of GCC itself as well as GCC's libraries.)
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02088.html
http://gcc.gnu.org/ml/gcc/2004-11/msg00255.html
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-05-11 10:20 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-11 4:54 [Bug preprocessor/48957] New: GCC's handling of include-fixed does not work well with --sysroot psmith at gnu dot org
2011-05-11 10:28 ` [Bug preprocessor/48957] " joseph at codesourcery dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).