public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: rbmj <rbmj@verizon.net>
To: Ian Lance Taylor <iant@google.com>
Cc: gcc-help@gcc.gnu.org
Subject: Re: Why is fixincludes not doing anything?
Date: Fri, 01 Jun 2012 17:32:00 -0000	[thread overview]
Message-ID: <4FC8FC71.8020307@verizon.net> (raw)
In-Reply-To: <mcrehq2eh8q.fsf@dhcp-172-18-216-180.mtv.corp.google.com>

[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]

On 05/29/2012 06:48 PM, Ian Lance Taylor wrote:
> Good job tracking it down.
>
> This is the patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00361.html
>
> This is where it was approved:
>
> http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00717.html
>
> So now at least you have some people to ask.
I got the same issues as noted in the patch message about CPU.  However, 
just disabling fixincludes outright seems like a kludgey way to solve 
the problem.  I think it would be better (less bad?) to only disable the 
machine_name fix.

As a bit of a hack (though IMHO less of a hack then just disabling the 
whole system), I disabled the machine_name fix and re-enabled 
fixincludes with the attached patch, as I *need* to change the header 
files to get gcc targeting vxworks to compile, and these are not changes 
that are easily accommodated with changes to GCC.  If I apply the patch, 
regenerate gcc/configure, and do a clean build fixincludes runs and the 
build finishes without errors.  The configure/build also works for a 
normal, native build.  Should I submit to -patches, in anticipation of 
submitting the hacks necessary to get a build without manually patching 
the headers?  Or is this not the right approach?

Thanks!

Robert Mason

[-- Attachment #2: 01-machine-name.patch --]
[-- Type: text/x-patch, Size: 2798 bytes --]

From fb4b751fd076adfc1596720bee4b4ba49f908431 Mon Sep 17 00:00:00 2001
From: rbmj <rbmj@verizon.net>
Date: Wed, 30 May 2012 08:16:57 -0400
Subject: [PATCH 1/5] Add ability to skip the machine_name fixincludes fix.

On some platforms, machine_name is overzealous, or even breaks things.
This patch adds the functionality to skip the machine_name 'fix' by
giving it an empty macro list.

gcc/configure: Regenerate
---
 fixincludes/mkfixinc.sh |    1 -
 gcc/Makefile.in         |   15 +++++++++++----
 gcc/configure.ac        |   14 ++++++++++++++
 3 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/fixincludes/mkfixinc.sh b/fixincludes/mkfixinc.sh
index 89e8ab7..6653fed 100755
--- a/fixincludes/mkfixinc.sh
+++ b/fixincludes/mkfixinc.sh
@@ -15,7 +15,6 @@ case $machine in
     i?86-*-mingw32* | \
     x86_64-*-mingw32* | \
     i?86-*-interix* | \
-    *-*-vxworks* | \
     powerpc-*-eabisim* | \
     powerpc-*-eabi*    | \
     powerpc-*-rtems*   | \
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 7b61b71..3534cd8 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -245,6 +245,9 @@ LINKER_FLAGS = $(CFLAGS)
 endif
 endif
 
+# Whether or not to run the machine_name fixincludes fix
+SKIP_MACHINE_NAME_FIX = @skip_machine_name_fix@
+
 # -------------------------------------------
 # Programs which operate on the build machine
 # -------------------------------------------
@@ -4129,10 +4132,14 @@ install-gcc-tooldir:
 
 macro_list: s-macro_list; @true
 s-macro_list : $(GCC_PASSES)
-	echo | $(GCC_FOR_TARGET) -E -dM - | \
-	  sed -n -e 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p' \
-		 -e 's/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \
-	  sort -u > tmp-macro_list
+	@if test "$(SKIP_MACHINE_NAME_FIX)" != "yes" ; then \
+		echo | $(GCC_FOR_TARGET) -E -dM - | \
+			sed -n -e 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p' \
+				-e 's/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \
+			sort -u > tmp-macro_list ; \
+	else \
+		echo > tmp-macro_list ; \
+	fi
 	$(SHELL) $(srcdir)/../move-if-change tmp-macro_list macro_list
 	$(STAMP) s-macro_list
 
diff --git a/gcc/configure.ac b/gcc/configure.ac
index a3a4038..d399ecc 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -5140,6 +5140,20 @@ if test x"${LINKER_HASH_STYLE}" != x; then
                                          [The linker hash style])
 fi
 
+# Check whether to enable the fixincludes machine_name hack on this platform
+case "${target}" in
+    *-*-vxworks*)
+        skip_machine_name_fix="yes"
+        ;;
+    *)
+        # Note that some platforms have fixincludes disabled by default so
+        # this will make no difference
+        skip_machine_name_fix="no"
+        ;;
+esac
+AC_SUBST(skip_machine_name_fix)
+
+
 # Configure the subdirectories
 # AC_CONFIG_SUBDIRS($subdirs)
 
-- 
1.7.5.4


  reply	other threads:[~2012-06-01 17:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-23 16:53 Fixincludes permanence & questions on cross compilers rbmj
2012-05-23 17:27 ` Jonathan Wakely
2012-05-23 18:04   ` rbmj
2012-05-25 12:08     ` Why is fixincludes not doing anything? (was: Re: Fixincludes permanence & questions on cross compilers) rbmj
2012-05-25 14:00       ` Ian Lance Taylor
2012-05-25 14:24         ` Why is fixincludes not doing anything? rbmj
2012-05-25 23:19           ` Ian Lance Taylor
2012-05-26 19:58             ` rbmj
     [not found]             ` <4FC128C8.1060604@verizon.net>
     [not found]               ` <mcrr4u6iufn.fsf@dhcp-172-18-216-180.mtv.corp.google.com>
2012-05-26 20:54                 ` rbmj
2012-05-27  6:08                   ` rbmj
2012-05-29 19:13             ` rbmj
2012-05-29 22:48               ` Ian Lance Taylor
2012-06-01 17:32                 ` rbmj [this message]
2012-06-01 19:44                   ` Ian Lance Taylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FC8FC71.8020307@verizon.net \
    --to=rbmj@verizon.net \
    --cc=gcc-help@gcc.gnu.org \
    --cc=iant@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).