[patch] Allow compiling against newer X11 headers
Andrew John Hughes
gnu_andrew at member.fsf.org
Mon Nov 2 11:40:48 PST 2009
2009/11/2 Vlastimil Babka <caster at gentoo.org>:
> Mark Wielaard wrote:
>> I added a configure check to see whether or not it is necessary to apply
>> the patch. This makes icedtea6 build out of the box on older (fedora 11)
>> and newer (fedora 12/rawhide) systems.
>> Let me know if it looks sane and I will update Hacking and the wiki with
>> the info.
> I was solving this problem in gentoo recently and I found the fedora
> patch a bit dangerous as it defines a structure from XShm.h manually.
> I've created another patch that is applied not to awt_GraphicsEnv.h but
> awt_GraphicsEnv.c (where the missing constant is actually used) and it
> just includes Xmd.h and shmproto.h to get the constant (surrounded by a
> MITSHM ifdef, as is the place of the actual constant usage). The
> awt_GraphicsEnv.h still includes Xshm.h with the struct that Fedora
> patch defines manually.
> But I have to admit I'm not an expert on this, maybe there were reasons
> behind the Fedora patch I don't know, but this one seems to work. I'm
> attaching it.
> I however didn't create configure check (mostly for lack of skills there
> :), we apply the patch conditionally in the gentoo ebuild for now.
> But I believe the logic of the check should go like this:
> - check if libXext (xext in pkg-config) is of version >= 1.1.1 - if it
> is, we know that we need also the shmproto.h
> - if yes, check that shmproto.h is present (or that xextproto is of
> version >=7.1.1), fail if it isn't
> If we check just for the existence of shmproto.h, it will fail in case
> libXext is of the new version (and the constant is no longer in XShm.h)
> but there is no xextproto and thus shmproto.h (it's only a build dep
> AFAIK so might not be present on all systems?).
> Hope it helps,
> --- /dev/null 2009-10-29 20:00:29.463258316 +0100
> +++ patches/icedtea-shmproto.patch 2009-10-29 21:02:36.000000000 +0100
> @@ -0,0 +1,13 @@
> +--- openjdk/jdk/src/solaris/native/sun/awt/awt_GraphicsEnv.c.orig 2009-10-29 21:01:01.000000000 +0100
> ++++ openjdk/jdk/src/solaris/native/sun/awt/awt_GraphicsEnv.c 2009-10-29 21:01:56.000000000 +0100
> +@@ -45,6 +45,10 @@
> + #include <stdlib.h>
> + #include "awt_GraphicsEnv.h"
> ++#ifdef MITSHM
> ++#include <X11/Xmd.h>
> ++#include <X11/extensions/shmproto.h>
> + #include "awt_Window.h"
> + #include "awt_util.h"
> + #include "gdefs.h"
> --- Makefile.am.orig 2009-10-29 21:35:23.000000000 +0100
> +++ Makefile.am 2009-10-29 21:35:50.000000000 +0100
> @@ -708,6 +708,7 @@
> patches/icedtea-explicit-target-arch.patch \
> patches/openjdk/6648816.patch \
> patches/openjdk/oj100103-debugger-socket-overflow.patch \
> + patches/icedtea-shmproto.patch \
> stamps/extract.stamp: stamps/download.stamp
Hi Mark, Vlastimil,
Having seen both patches before, I'd personally prefer we just added
the necessary headers if that works, rather than the additional cruft
we have in the Fedora patch. We should do that in awt_GraphicsEnv.h
though, as in the Fedora patch, which would also remove the need for
the #ifdef MITSHM (it's in awt_GraphicsEnv.h already). So basically
the Fedora patch but without the removal of the XShm.h include and the
Though I've been aware of this for a while, I deliberately haven't
upgraded my own build systems to the new version because it will break
OpenJDK builds for which we don't yet have a solution. Does anyone
know of some versioning defines in the X headers that would avoid us
having to use a configure check, and thus allow the patch to be
submitted upstream? I believe the change
in libXext 1.1.1 as Vlastimil says, but is there a way of detecting
that other than with autoconf?
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
More information about the distro-pkg-dev