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
