RFC: architecture define probably masks variable names in header files

[Kelly O'Hair]

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