diff mbox

GCC for GNU Hurd: MACH built-in preprocessor macro (was: gdb: FTBFS on hurd-i386 (for review))

Message ID 874nl4a8d4.fsf@kepler.schwinge.homeip.net
State Accepted, archived
Headers show

Commit Message

Thomas Schwinge Nov. 5, 2012, 6:09 a.m. UTC 
Hi!

On Fri, 28 Sep 2012 09:56:41 +0200, Samuel Thibault <samuel.thibault@gnu.org> wrote:
> Thomas Schwinge, le Thu 27 Sep 2012 09:15:23 +0200, a écrit :
> > On Wed, 26 Sep 2012 16:02:29 +0200, Svante Signell <svante.signell@telia.com> wrote:
> > > gdb does not build from source any longer since gdb-multiarch packages
> > > was enabled in 7.4.1-1. The build problems are due to two reasons:
> > 
> > I also once had a look and came to the same conclusion.
> > 
> > > First the reserved keyword MACH is defined in include/objcode/h8300.h
> > > causing problems since gcc defines it for GNU/Hurd. 
> > 
> > Correct.  And I wonder if that isn't a name-space violation?  This is
> > what I meant to look up when working on this two months ago, but then it
> > seems I again got distracted by other issues.  Roland, do you have any
> > comments regarding that?
> > 
> > [GCC]/gcc/config/gnu.h:
> >     [...]
> >     #undef GNU_USER_TARGET_OS_CPP_BUILTINS
> >     #define GNU_USER_TARGET_OS_CPP_BUILTINS()               \
> >         do {                                        \
> >             builtin_define ("__gnu_hurd__");        \
> >             builtin_define ("__GNU__");             \
> >             builtin_define_std ("unix");            \
> >             builtin_define_std ("MACH");            \
> >             builtin_assert ("system=gnu");          \
> >             builtin_assert ("system=mach");         \
> >             builtin_assert ("system=unix");         \
> >             builtin_assert ("system=posix");        \
> >         } while (0)
> > 
> >     $ gcc -dM -E -x c - < /dev/null | grep -i mach
> >     #define __MACH 1
> >     #define __MACH__ 1
> >     #define MACH 1
> 
> On Linux i386, both "linux" and "i386" macros are defined, which poses
> its own problems too.

(Let's pause for a moment in remembrance of the »glibc vs. i686 defined«
issue that would nearly have seen its 10th anniversary these days.)

> I'd indeed tend to say that defining a non-underscored macro is only a
> way for troubles.
> 
> > Could we/should we remove the latter one?  Though, I have no idea how
> > much user code is relying on MACH being #defined.  I had a colleague
> > check, and Apple/Darwin systems do *only* #define __MACH__ (as well as
> > __APPLE__).

Here is the straightforward patch.  With it, only the __MACH__ built-in
preprocessor macro remains, and we get:

    [...]
     Fixing headers into /home/thomas/tmp/gnu-0/obj/gcc/gcc/include-fixed for
     i686-pc-gnu target
    -Forbidden identifiers: MACH i386 unix
    +Forbidden identifiers: i386 unix
    [...]

These two are to remain.


Samuel, is there any way you can unpack all Debian source packages on a
Debian machine, and run a recursive grep command (I can work out a
suitable regex) to see where removing the MACH or __MACH built-in
preprocessor macros might cause trouble?


Grüße,
 Thomas

Comments

Samuel Thibault Nov. 5, 2012, 11:22 a.m. UTC | #1 
Thomas Schwinge, le Mon 05 Nov 2012 07:09:43 +0100, a écrit :
> Samuel, is there any way you can unpack all Debian source packages on a
> Debian machine, and run a recursive grep command (I can work out a
> suitable regex) to see where removing the MACH or __MACH built-in
> preprocessor macros might cause trouble?

Sure!

Samuel
Samuel Thibault Nov. 7, 2012, 12:11 a.m. UTC | #2 
Thomas Schwinge, le Mon 05 Nov 2012 07:09:43 +0100, a écrit :
> Samuel, is there any way you can unpack all Debian source packages on a
> Debian machine, and run a recursive grep command (I can work out a
> suitable regex) to see where removing the MACH or __MACH built-in
> preprocessor macros might cause trouble?

Heh, it had to happen just now: http://codesearch.debian.net/ was
announced :)

Samuel
Thomas Schwinge Feb. 6, 2013, 11:17 p.m. UTC | #3 
Hi!

On Mon, 05 Nov 2012 07:09:43 +0100, I wrote:
> On Fri, 28 Sep 2012 09:56:41 +0200, Samuel Thibault <samuel.thibault@gnu.org> wrote:
> > Thomas Schwinge, le Thu 27 Sep 2012 09:15:23 +0200, a écrit :
> > > On Wed, 26 Sep 2012 16:02:29 +0200, Svante Signell <svante.signell@telia.com> wrote:
> > > > gdb does not build from source any longer since gdb-multiarch packages
> > > > was enabled in 7.4.1-1. The build problems are due to two reasons:
> > > 
> > > I also once had a look and came to the same conclusion.
> > > 
> > > > First the reserved keyword MACH is defined in include/objcode/h8300.h
> > > > causing problems since gcc defines it for GNU/Hurd. 
> > > 
> > > Correct.  And I wonder if that isn't a name-space violation?  This is
> > > what I meant to look up when working on this two months ago, but then it
> > > seems I again got distracted by other issues.  Roland, do you have any
> > > comments regarding that?
> > > 
> > > [GCC]/gcc/config/gnu.h:
> > >     [...]
> > >     #undef GNU_USER_TARGET_OS_CPP_BUILTINS
> > >     #define GNU_USER_TARGET_OS_CPP_BUILTINS()               \
> > >         do {                                        \
> > >             builtin_define ("__gnu_hurd__");        \
> > >             builtin_define ("__GNU__");             \
> > >             builtin_define_std ("unix");            \
> > >             builtin_define_std ("MACH");            \
> > >             builtin_assert ("system=gnu");          \
> > >             builtin_assert ("system=mach");         \
> > >             builtin_assert ("system=unix");         \
> > >             builtin_assert ("system=posix");        \
> > >         } while (0)
> > > 
> > >     $ gcc -dM -E -x c - < /dev/null | grep -i mach
> > >     #define __MACH 1
> > >     #define __MACH__ 1
> > >     #define MACH 1
> > 
> > On Linux i386, both "linux" and "i386" macros are defined, which poses
> > its own problems too.
> 
> (Let's pause for a moment in remembrance of the »glibc vs. i686 defined«
> issue that would nearly have seen its 10th anniversary these days.)
> 
> > I'd indeed tend to say that defining a non-underscored macro is only a
> > way for troubles.
> > 
> > > Could we/should we remove the latter one?  Though, I have no idea how
> > > much user code is relying on MACH being #defined.  I had a colleague
> > > check, and Apple/Darwin systems do *only* #define __MACH__ (as well as
> > > __APPLE__).
> 
> Here is the straightforward patch.  With it, only the __MACH__ built-in
> preprocessor macro remains, and we get:
> 
>     [...]
>      Fixing headers into /home/thomas/tmp/gnu-0/obj/gcc/gcc/include-fixed for
>      i686-pc-gnu target
>     -Forbidden identifiers: MACH i386 unix
>     +Forbidden identifiers: i386 unix
>     [...]
> 
> These two are to remain.
> 
> diff --git gcc/config/gnu.h gcc/config/gnu.h
> index dddbcbf..4d9449e 100644
> --- gcc/config/gnu.h
> +++ gcc/config/gnu.h
> @@ -34,7 +34,7 @@ along with GCC.  If not, see <http://www.gnu.org/licenses/>.
>  	builtin_define ("__gnu_hurd__");	\
>  	builtin_define ("__GNU__");		\
>  	builtin_define_std ("unix");		\
> -	builtin_define_std ("MACH");		\
> +	builtin_define ("__MACH__");		\
>  	builtin_assert ("system=gnu");		\
>  	builtin_assert ("system=mach");		\
>  	builtin_assert ("system=unix");		\

Committed to trunk as r195826.  Samuel, please port to active Debian GCC
branches.


Grüße,
 Thomas
diff mbox

Patch

diff --git gcc/config/gnu.h gcc/config/gnu.h
index dddbcbf..4d9449e 100644
--- gcc/config/gnu.h
+++ gcc/config/gnu.h
@@ -34,7 +34,7 @@  along with GCC.  If not, see <http://www.gnu.org/licenses/>.
 	builtin_define ("__gnu_hurd__");	\
 	builtin_define ("__GNU__");		\
 	builtin_define_std ("unix");		\
-	builtin_define_std ("MACH");		\
+	builtin_define ("__MACH__");		\
 	builtin_assert ("system=gnu");		\
 	builtin_assert ("system=mach");		\
 	builtin_assert ("system=unix");		\