I very much suspect that this -D$(ARCH) could be removed with no consequences.
The difficult part would be verifying it.

C macros are a very powerful tool, but some of the global names we have chosen
over the years have come back to haunt us. :^(

-kto

Martin Buchholz wrote:
Christian,

I care, and agree with you.

I recall many years ago, debugging a mysterious failure building Emacs.
Building on Solaris-Sparc defined the symbol "sparc",
and this caused the build to fail, only if a component of the
current working directory was "sparc".

Martin

Christian Thalinger wrote:
On Wed, 2008-01-16 at 23:04 +0100, Christian Thalinger wrote:
Hi!

Today I noticed that it's not a good idea to use an architecture define
as done in OpenJDK:

CPPFLAGS_COMMON = -D$(ARCH) -DARCH='"$(ARCH)"' -DLINUX $(VERSION_DEFINES) \
                  -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT

The -D$(ARCH) e.g. on an Alpha system makes big problems because a lot
of variables are called "alpha" in GUI code.

I tried to patch the OpenJDK code in IcedTea but then I reached a point
where it's not possible to fix the issue:

/usr/include/png.h:

typedef struct png_color_8_struct
{
  png_byte red;   /* for use in red green blue files */
  png_byte green;
  png_byte blue;
  png_byte gray;  /* for use in grayscale files */
  png_byte alpha; /* for alpha channel files */
} png_color_8;

This won't work.

Normally build systems use architecture defines as __ALPHA__ or
__alpha__ (these are also defined by the C compiler).

Any chance to get this thing changed/fixed upstream in the OpenJDK code?
As I can't think of another solution of that problem...

Probably someone decides to name a function argument "sparc"
someday... ;-)
So... noone cares?

- twisti

Reply via email to