xlib_libX11: fix compilation of makekeys
PATCH 1/1 xlib_libX11: fix compilation of makekeys
xlib_libX11 builds a makekeys executable for the host, but uses the targets X11_CFLAGS. This leads to build failures like
http://autobuild.buildroot.net/results/411eb3aefea859a7e31986a44acd50b475f174cb/
This problem was introduced by the version bump, because then also the AUTORECONF was removed so the existing fix didn't work anymore.
As a slightly cleaner solution, just remove X11_CFLAGS from the Makefile. We know we don't need it, because the X11 stuff is in $(HOST_DIR)/usr/include which is already in HOST_CFLAGS.
--- package/x11r7/xlib_libX11/xlib_libX11.mk | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-)
package/x11r7/xlib_libX11/xlib_libX11.mk +6 -13
@@ -19,21 +19,14 @@ HOST_XLIB_LIBX11_CONF_OPT = \ # src/util/makekeys is executed at build time to generate ks_tables.h, so # it should get compiled for the host. The libX11 makefile unfortunately -# doesn't know about cross compilation so this doesn't work. -# Long term, we should probably teach it about HOSTCC / HOST_CFLAGS, but for -# now simply disable the src/util Makefile and build makekeys by hand in -# advance -define XLIB_LIBX11_DISABLE_MAKEKEYS_BUILD - echo '' > $(@D)/src/util/Makefile.am +# doesn't have X11_CFLAGS_FOR_BUILD so this doesn't work. For buildroot, +# we now the X11 includes are in $(HOST_DIR)/usr/include with are already +# in the CFLAGS_FOR_BUILD, so we can just remove the X11_CFLAGS +define XLIB_LIBX11_DISABLE_MAKEKEYS_X11_CFLAGS + $(SED) '/X11_CFLAGS/d' $(@D)/src/util/Makefile* endef -XLIB_LIBX11_POST_EXTRACT_HOOKS += XLIB_LIBX11_DISABLE_MAKEKEYS_BUILD - -define XLIB_LIBX11_BUILD_MAKEKEYS_FOR_HOST - cd $(@D)/src/util && $(HOSTCC) $(HOST_CFLAGS) -o makekeys makekeys.c -endef - -XLIB_LIBX11_POST_CONFIGURE_HOOKS += XLIB_LIBX11_BUILD_MAKEKEYS_FOR_HOST +XLIB_LIBX11_POST_PATCH_HOOKS += XLIB_LIBX11_DISABLE_MAKEKEYS_X11_CFLAGS $(eval $(autotools-package)) $(eval $(host-autotools-package))
Signature · 1 line
tg: (9de85f7..) t/xlib_libX11-makekeys (depends on: master)
PATCH 1/1 xlib_libX11: fix compilation of makekeys
Arnout,
Quoted 4 lines · Arnout Vandecappelle (Essensium/Mind)
xlib_libX11builds a makekeys executable for the host, but uses the targetsX11_CFLAGS. This leads to build failures like
http://autobuild.buildroot.net/results/411eb3aefea859a7e31986a44acd50b475f174cb/
Quoted 8 lines
This problem was introduced by the version bump, because then also the AUTORECONF was removed so the existing fix didn't work anymore.
As a slightly cleaner solution, just remove
X11_CFLAGSfrom theMakefile. We know we don't need it, because the X11 stuff is in $(HOST_DIR)/usr/include which is already inHOST_CFLAGS.
Hasn't this broken the xlib-x11 build? See
http://autobuild.buildroot.org/results/6a5a16f901215acca06cb7a89f7d7fb0bc1741af/build-end.log.
It is including a host header (Xos.h) which itself includes target headers. Sounds really wrong.
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 xlib_libX11: fix compilation of makekeys
Quoted 15 lines · Thomas Petazzoni
Arnout,
Quoted 11 lines · Arnout Vandecappelle (Essensium/Mind)
xlib_libX11builds a makekeys executable for the host, but uses the targetsX11_CFLAGS. This leads to build failures like
http://autobuild.buildroot.net/results/411eb3aefea859a7e31986a44acd50b475f174cb/This problem was introduced by the version bump, because then also the AUTORECONF was removed so the existing fix didn't work anymore.
As a slightly cleaner solution, just remove
X11_CFLAGSfrom theMakefile. We know we don't need it, because the X11 stuff is in $(HOST_DIR)/usr/include which is already inHOST_CFLAGS.
Quoted 7 lines
Quoted 1 line
Signed-off-by Arnout Vandecappelle (Essensium/Mind)<[email protected]>Hasn't this broken the xlib-x11 build? See
http://autobuild.buildroot.org/results/6a5a16f901215acca06cb7a89f7d7fb0bc1741af/build-end.log.It is including a host header (
Xos.h) which itself includes target headers. Sounds really wrong.
Indeed, and this patch fixes that. It's a different symptom of the same
error: makekeys is a host binary, but it's built with target CFLAGS (X11_CFLAGS = -I$(STAGING_DIR)/usr/include). This will barf in surprising ways.
(That is, unless you have an autobuilder that runs against a git tree that
has already integrated this patch; if that is the case, then I made a mistake somewhere.)
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286540 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
PATCH 1/1 xlib_libX11: fix compilation of makekeys
Dear Arnout Vandecappelle,
Quoted 8 lines · Arnout Vandecappelle
Indeed, and this patch fixes that. It's a different symptom of the same
error: makekeys is a host binary, but it's built with target CFLAGS (X11_CFLAGS= -I$(STAGING_DIR)/usr/include). This will barf in surprising ways.(That is, unless you have an autobuilder that runs against a git tree that
has already integrated this patch; if that is the case, then I made a mistake somewhere.)
Aaah, your patch hasn't been integrated yet. My bad. Peter, could you merge Arnout's patch then?
Thanks,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 xlib_libX11: fix compilation of makekeys
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Thomas> Dear Arnout Vandecappelle,
Quoted 8 lines · Arnout Vandecappelle
Quoted 8 lines
Indeed, and this patch fixes that. It's a different symptom of the same
error: makekeys is a host binary, but it's built with target CFLAGS (X11_CFLAGS= -I$(STAGING_DIR)/usr/include). This will barf in surprising ways.(That is, unless you have an autobuilder that runs against a git tree that has already integrated this patch; if that is the case, then I made a mistake somewhere.)
Thomas> Aaah, your patch hasn't been integrated yet. My bad. Peter, could you Thomas> merge Arnout's patch then?
I did this morning (but forgot to push before now).
Signature · 1 line
Bye, Peter Korsgaard