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).