RESOLVED FIXED 17415
GTK Build (using autotools) on Mac OS (DarwinPorts) Fails
https://bugs.webkit.org/show_bug.cgi?id=17415
Summary GTK Build (using autotools) on Mac OS (DarwinPorts) Fails
Brent Fulgham
Reported 2008-02-17 16:48:05 PST
Mac OS does not have a standard ICU installation at /usr/include/unicode (and obviously does not have a GTK installation either). Using DarwinPorts to install GTK, CURL, ICU, and the other GTK build requirements results in a build failure (see attached buildlog). The problem seems to be that certain macro defines required by ICU are not specified when WebKit builds. Relevant libraries: OS X (10.5.2) on Intel gcc 4.0.1 autoconf 2.61 automake 1.10.1 libtool 1.5.24 GTK+ 2.12.4 GTK-- 2.12.0 ICU 3.8 (also tried with 3.6) Cairo 1.4.14 Curl 7.18.0
Attachments
Build log showing the failure (167.90 KB, text/plain)
2008-02-17 16:55 PST, Brent Fulgham
no flags
Update build rules for Mac OS (GTK+) (1.85 KB, patch)
2008-03-01 23:03 PST, Brent Fulgham
darin: review+
Revised patch using ICU_CPPFLAGS instead of "$(prefix)/include" (1.94 KB, patch)
2008-03-02 20:00 PST, Brent Fulgham
alp: review+
Brent Fulgham
Comment 1 2008-02-17 16:55:33 PST
Created attachment 19181 [details] Build log showing the failure
Brent Fulgham
Comment 2 2008-02-29 22:10:07 PST
*** Bug 17517 has been marked as a duplicate of this bug. ***
Brent Fulgham
Comment 3 2008-02-29 22:20:50 PST
The specific cause of the build failure is that it is attempting to load ${SYSTEM}/include/unicode/utf8.h (the installed ICU header directory). But because of the include path priorities, it finds Webkit/JavaScriptCore/wtf/unicode/UTF8.h On many systems this wouldn't be a problem, but on the Mac the directory structure can be case insensitive, so it accepts the UTF8.h header, which does not define the necessary elements (e.g., UCONFIG_NO_NORMALIZATION) to properly configure and build.
Brent Fulgham
Comment 4 2008-03-01 12:03:46 PST
Correcting the GNUmakefile include path ordering so that the system ICU (/opt/local in my case) allows the compile to continue. Unfortunately, a linker error is encountered later, but I do not believe this is related to the original problem.
Brent Fulgham
Comment 5 2008-03-01 23:03:17 PST
Created attachment 19480 [details] Update build rules for Mac OS (GTK+) Proposed correction to support GTK+ build on Mac OS X.
Darin Adler
Comment 6 2008-03-02 18:32:48 PST
Comment on attachment 19480 [details] Update build rules for Mac OS (GTK+) Looks fine to me, although I'm not an expert on the GTK port. Setting review+. GTK folks, please let me know if I'm being too liberal reviewing GTK-specific patches and if so, I'll steer clear in the future.
Alp Toker
Comment 7 2008-03-02 18:45:04 PST
(In reply to comment #6) > (From update of attachment 19480 [details] [edit]) > Looks fine to me, although I'm not an expert on the GTK port. Setting review+. > > GTK folks, please let me know if I'm being too liberal reviewing GTK-specific > patches and if so, I'll steer clear in the future. > In this case Brent was just trying out an alternative to this fix on #webkit but it's fine to be liberal on build fixes and WebCore changes. We wouldn't land it until it worked right anyway. We could actually do with advice (but not necessarily r+) on the API changes currently waiting for review if you have some time to spare. I've been a bit short of time to investigate the impact of these changes.
Brent Fulgham
Comment 8 2008-03-02 20:00:15 PST
Created attachment 19487 [details] Revised patch using ICU_CPPFLAGS instead of "$(prefix)/include" Revised patch using ICU_CPPFLAGS instead of "$(prefix)/include"
Alp Toker
Comment 9 2008-03-02 21:12:50 PST
Landed in r30707 with a couple of tweaks.
Note You need to log in before you can comment on or make changes to this bug.