Hi,
I recently faced problems while building GCC caused by a system header
being broken by the machine_name fix from fixincludes [1]. And
apparently I am not the first one [2][3].
After digging into the fixincludes code, I found the following comment
on fixincludes/fixinc.in:
> # # # # # # # # # # # # # # # # # # # # #
> #
> # Check to see if the machine_name fix needs to be disabled.
> #
> # On some platforms, machine_name doesn't work properly and
> # breaks some of the header files. Since everything works
> # properly without it, just wipe the macro list to
> # disable the fix.
Indeed adding the target to the case that follows this comment did the
trick for me:
diff --git a/fixincludes/fixinc.in b/fixincludes/fixinc.in
index 15cbaa23544..c0791454b9c 100755
--- a/fixincludes/fixinc.in
+++ b/fixincludes/fixinc.in
@@ -136,6 +136,9 @@ fi
# disable the fix.
case "${target_canonical}" in
+ powerpc*-*-linux-*)
+ test -f ${MACRO_LIST} && echo > ${MACRO_LIST}
+ ;;
*-*-vxworks*)
test -f ${MACRO_LIST} && echo > ${MACRO_LIST}
;;
--
2.21.1
I haven't noticed any harm done by disabling this fix for my specific
case. From what I could understand from the code and from the diffs of
the 'fixed' headers, this fix just surrounds some identifiers with '__'
on #ifdef/#define/#include lines.
Since even the source code states 'everything works properly without
it', is this fix still really needed? Would it make any sense to disable
machine_name by default for other targets upstream?
Note I'm not particularly familiar with the historical need for this, my
question is based specially on the comment quoted above and my empirical
tests.
[1] https://gcc.gnu.org/ml/gcc-help/2020-02/msg00023.html
[2] https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01901.html
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91085
Cheers,
Matheus Castanho
