Bug 84095

Summary: Only depend on xrender if x11 is being used
Product: WebKit Reporter: Jeremy Huddleston Sequoia <jeremyhu>
Component: WebKitGTKAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: chkang514, jeremyhu, michael.duwei, mrobinson, webkit.review.bot, zan
Priority: P2 Keywords: EasyFix
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
URL: https://trac.macports.org/ticket/34086
Attachments:
Description Flags
I made a simple patch for this bug.
none
Patch none

Description Jeremy Huddleston Sequoia 2012-04-16 16:22:36 PDT
http://trac.macports.org/ticket/34086

configure.ac contains:
# check for XRender under Linux/Unix. Some linkers require explicit
# linkage (like GNU Gold), so we cannot rely on GTK+ pulling XRender
if test "$os_win32" = "no"; then
   PKG_CHECK_MODULES([XRENDER], [xrender])
   AC_SUBST([XRENDER_CFLAGS])
   AC_SUBST([XRENDER_LIBS])
fi

But that logic is incorrect.  You should be checking for xrender based on target (x11), not OS.  This incorrectly results in xrender being pulled in for the quartz target, and it incorrectly prevents xrender from being pulled in on the win/x11 target.
Comment 1 Jeremy Huddleston Sequoia 2012-04-19 09:39:25 PDT
Here is a patch:
https://trac.macports.org/raw-attachment/ticket/34086/xrender-check.patch


--- configure.orig	2012-04-18 17:55:13.000000000 -0500
+++ configure	2012-04-18 17:56:11.000000000 -0500
@@ -22086,7 +22086,7 @@
 
 # check for XRender under Linux/Unix. Some linkers require explicit
 # linkage (like GNU Gold), so we cannot rely on GTK+ pulling XRender
-if test "$os_win32" = "no"; then
+if test "$with_target" = "x11"; then
 
 pkg_failed=no
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for XRENDER" >&5
Comment 2 Changhun Kang 2012-10-23 03:03:13 PDT
Created attachment 170103 [details]
I made a simple patch for this bug.
Comment 3 Jeremy Huddleston Sequoia 2012-10-23 08:57:55 PDT
That's exactly the same patch that I provided in the link in the previous comment...
Comment 4 Changhun Kang 2012-10-23 17:12:41 PDT
I appreciate for your guide.
Is there anything i missed?
> That's exactly the same patch that I provided in the link in the previous comment...
Comment 5 Jeremy Huddleston Sequoia 2012-10-28 13:37:57 PDT
(In reply to comment #4)
> I appreciate for your guide.
> Is there anything i missed?
> > That's exactly the same patch that I provided in the link in the previous comment...

No, I'm saying that's exactly what I had already, so:

Reviewed-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Tested-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>

Sorry, I'm not familiar with the commit process within webkit and have just been filing bugs.  If it should've been sent to a list or made an attachment, please let me know for next time.
Comment 6 Benjamin Poulain 2013-02-18 18:36:59 PST
Comment on attachment 170103 [details]
I made a simple patch for this bug.

This looks out of date, the patch does not apply.
Comment 7 Jeremy Huddleston Sequoia 2013-02-18 20:19:18 PST
It's a trivial 1-line patch.  Surely you can rebase it.
Comment 8 Jeremy Huddleston Sequoia 2013-02-18 23:27:16 PST
And it applies fine to 1.11.5
Comment 9 Zan Dobersek 2013-02-19 00:34:45 PST
The configuration system used by the Autotools build was reworked recently. The change should now fit in here:
http://trac.webkit.org/browser/trunk/Source/autotools/FindDependencies.m4
Comment 10 Changhun Kang 2013-02-19 00:48:06 PST
Created attachment 189013 [details]
Patch
Comment 11 WebKit Review Bot 2013-02-19 09:03:24 PST
Comment on attachment 189013 [details]
Patch

Clearing flags on attachment: 189013

Committed r143344: <http://trac.webkit.org/changeset/143344>
Comment 12 WebKit Review Bot 2013-02-19 09:03:28 PST
All reviewed patches have been landed.  Closing bug.