public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug preprocessor/20472] New: Rre-processor header file search list wrong with --exec-prefix
@ 2005-03-14 17:40 gml4410 at ggr dot co dot uk
2005-03-14 17:46 ` [Bug preprocessor/20472] " pinskia at gcc dot gnu dot org
2005-03-14 18:09 ` gml4410 at ggr dot co dot uk
0 siblings, 2 replies; 3+ messages in thread
From: gml4410 at ggr dot co dot uk @ 2005-03-14 17:40 UTC (permalink / raw)
To: gcc-bugs
Fix patch supplied at end...
---
I have a problem (on Irix6.5, Solaris2.8, OSF1v5.1 and Linux) when I
include the use of --exec-prefix in the build (which allows a common
location for the man pages, info files and common c++ header files).
The problem is that the some of the directory locations used to
search for header files are nonsense.
I decided to see where "make install" actually installs the files and
see how to match that up with the Makefile.in setting of
PREPROCESSOR_DEFINES.
I've had a look at the way gcc is built. It builds (part of) the
pre-processor (cppdefault.c) by using a set of definitions passed in
fromn the Makefile, but these don't actually correspond to where "make
install" puts files when you specify a --exec-prefix which is not under
--prefix.
Even if you don't specify a --exec-prefix the pathnames used are
somewhat odd.
I've build gcc with and without using --exec-prefix with and without
my patch (see end).
For gcc compilations the include paths used do not change as a result
of this patch.
For g++ compilations the include paths change as follows:
A) Without using --exec-prefix:
/local/single/arch/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3
/local/single/arch/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3/i686-pc-linux-gnu
/local/single/arch/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3/backward
becomes:
/local/single/arch/include/c++/3.4.3
/local/single/arch/include/c++/3.4.3/i686-pc-linux-gnu
/local/single/arch/include/c++/3.4.3/backward
which are the same locations, but using a more sensible (direct) route.
B) With --exec-prefix set
When I use --exec-prefix to place it under a separate location to
--prefix (well, it's really the reverse...) then what was:
ignoring nonexistent directory
"/local/shared/arch/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../../../../include/c++/3.4.3"
ignoring nonexistent directory
"/local/shared/arch/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../../../../include/c++/3.4.3/i686-pc-linux-gnu"
ignoring nonexistent directory
"/local/shared/arch/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../../../../include/c++/3.4.3/backward"
becomes
/local/shared/common/include/c++/3.4.3
/local/shared/common/include/c++/3.4.3/i686-pc-linux-gnu
/local/shared/common/include/c++/3.4.3/backward
and things work as expected.
NOTE: that even with this patch installed the setting of
TOOL_INCLUDE_DIR still corresponds to a non-existent directory.
I haven't tested this on any cross-compilation setup.
This does not change the setting of gcc_tooldir, which is equally
wrongly set, but it only seems to be used in cross-compilation.
The patch is a trivial change from using $(gcc_gxx_include_dir) to
using $(gxx_include_dir).
==========
--- gcc/Makefile.in.orig 2004-10-18 17:00:39.000000000 +0100
+++ gcc/Makefile.in 2005-03-14 10:55:15.000000000 +0000
@@ -2332,12 +2332,15 @@
#\f
# Remake cpp and protoize.
-
+# Fix to correspond to where make install puts things
+# (at least for standard buils with --prefix and
+# --exec-prefix + --prefix)
+#
PREPROCESSOR_DEFINES = \
-DGCC_INCLUDE_DIR=\"$(libsubdir)/include\" \
- -DGPLUSPLUS_INCLUDE_DIR=\"$(gcc_gxx_include_dir)\" \
- -DGPLUSPLUS_TOOL_INCLUDE_DIR=\"$(gcc_gxx_include_dir)/$(target_noncanonical)\" \
- -DGPLUSPLUS_BACKWARD_INCLUDE_DIR=\"$(gcc_gxx_include_dir)/backward\" \
+ -DGPLUSPLUS_INCLUDE_DIR=\"$(gxx_include_dir)\" \
+ -DGPLUSPLUS_TOOL_INCLUDE_DIR=\"$(gxx_include_dir)/$(target_noncanonical)\" \
+ -DGPLUSPLUS_BACKWARD_INCLUDE_DIR=\"$(gxx_include_dir)/backward\" \
-DLOCAL_INCLUDE_DIR=\"$(local_includedir)\" \
-DCROSS_INCLUDE_DIR=\"$(CROSS_SYSTEM_HEADER_DIR)\" \
-DTOOL_INCLUDE_DIR=\"$(gcc_tooldir)/include\" \
--
Summary: Rre-processor header file search list wrong with --exec-
prefix
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gml4410 at ggr dot co dot uk
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: ANY
GCC host triplet: ANY
GCC target triplet: ANY
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20472
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug preprocessor/20472] Rre-processor header file search list wrong with --exec-prefix
2005-03-14 17:40 [Bug preprocessor/20472] New: Rre-processor header file search list wrong with --exec-prefix gml4410 at ggr dot co dot uk
@ 2005-03-14 17:46 ` pinskia at gcc dot gnu dot org
2005-03-14 18:09 ` gml4410 at ggr dot co dot uk
1 sibling, 0 replies; 3+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-03-14 17:46 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-14 17:46 -------
> which are the same locations, but using a more sensible (direct) route.
This is not true. What happens with symbolic links and stuff.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20472
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug preprocessor/20472] Rre-processor header file search list wrong with --exec-prefix
2005-03-14 17:40 [Bug preprocessor/20472] New: Rre-processor header file search list wrong with --exec-prefix gml4410 at ggr dot co dot uk
2005-03-14 17:46 ` [Bug preprocessor/20472] " pinskia at gcc dot gnu dot org
@ 2005-03-14 18:09 ` gml4410 at ggr dot co dot uk
1 sibling, 0 replies; 3+ messages in thread
From: gml4410 at ggr dot co dot uk @ 2005-03-14 18:09 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From gml4410 at ggr dot co dot uk 2005-03-14 18:09 -------
> > which are the same locations, but using a more sensible (direct) route.
>
> This is not true. What happens with symbolic links and stuff.
If there are symbolic links involved then the "direct" path is going to be
the one I really want to use.
With:
/local/single/arch/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3
a) if symbolic links led me to a place other than
/local/single/arch/include/c++/3.4.3
then it would (almost?) certainly *not* be what was actually wanted
b) some OSes may refuse to open path su8ch as this unless
/local/single/arch/lib/gcc/i686-pc-linux-gnu/3.4.3
actually exists (in this case it does, but perhaps teher are cases when
it does not?).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20472
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-03-14 18:09 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-03-14 17:40 [Bug preprocessor/20472] New: Rre-processor header file search list wrong with --exec-prefix gml4410 at ggr dot co dot uk
2005-03-14 17:46 ` [Bug preprocessor/20472] " pinskia at gcc dot gnu dot org
2005-03-14 18:09 ` gml4410 at ggr dot co dot uk
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).