Summary: | >=net-libs/webkit-gtk-2.8 doesn't build on ia64 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Émeric Maschino <emeric.maschino> |
Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | emeric.maschino, esigra, ia64 |
Priority: | Normal | Keywords: | EBUILD, PATCH, REGRESSION |
Version: | unspecified | ||
Hardware: | IA64 | ||
OS: | Linux | ||
URL: | https://bugs.webkit.org/show_bug.cgi?id=129992 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 513888 | ||
Bug Blocks: | 545082 | ||
Attachments: |
build.log
environment 1.patch webkit-gtk-2.8.5 CMakeOuput.log Add ia64 as supported CPU to JSC Update webkit-gtk-2.8.5 CMakeOutput.log with 2.patch applied Updated build.log with 1.patch and 2.patch applied Fix webkit-gtk-2.8.5 ia64 build Updated webkit-gtk-2.8.5.ebuild to build on ia64 Diff between webkit-gtk-2.8.5.ebuild in portage and attachment #416038 |
Description
Émeric Maschino
2015-07-20 20:24:31 UTC
Created attachment 407296 [details]
build.log
Created attachment 407300 [details]
environment
We will need to look at other distributions as upstream don't care about ia64 for ages... (In reply to Pacho Ramos from comment #3) > We will need to look at other distributions as upstream don't care about > ia64 for ages... Pacho, what do you mean by "other distributions"? Linux distributions??? Gentoo is the only one still "supporting" ia64. If you mean JavaScript "distribution", the only working implementation for ia64 is SpiderMonkey. Émeric Yeah... in that case I guess we will need to start dropping keywords :S (In reply to Pacho Ramos from comment #5) > Yeah... in that case I guess we will need to start dropping keywords :S Like dropping gnome-online-accounts, as most of the problems come from it? And then ensure that GNOME core packages can be emerged without g-o-a and thus without webkit-gtk? Today, eclean dist -d was complaining about no more available totem-3.14 and yelp-3.14 in portage tree. Indeed, only 3.16 versions are now available. The beginning of the end for GNOME on ia64? I'm not familiar enough with the GNOME project, but what's preventing the GNOME applications that currently depend on webkit-gtk to use spidermonkey as JS implementation? From [1], it even looks like this is fortunately the case (well, for ia64) for the most important GNOME 3 component: GNOME Shell. Still from [1], JS implementation in GNOME is either Gjs or Seed. How is it then that some GNOME applications have direct dependency on webkit-gtk rather than Seed? Émeric [1] https://wiki.gnome.org/JavaScript Looking to the cmake config error... could you provide the pointed /var/tmp/portage/net-libs/webkit-gtk-2.8.3/work/webkit-gtk-2.8.3_build/CMakeFiles/CMakeOutput.log to try to know what concrete check is failing? Created attachment 412670 [details, diff]
1.patch
Also try after applying this patch please
webkit is not needed for JS but for webviews in "online accounts". This applet is already optional at g-c-c level afaik. Created attachment 412696 [details]
webkit-gtk-2.8.5 CMakeOuput.log
(In reply to Pacho Ramos from comment #7) > Looking to the cmake config error... could you provide the pointed > /var/tmp/portage/net-libs/webkit-gtk-2.8.3/work/webkit-gtk-2.8.3_build/ > CMakeFiles/CMakeOutput.log to try to know what concrete check is failing? webkit-gtk-2.8.3 is no more in portage tree, so please find in attachment 412696 [details] the required log for webkit-gtk-2.8.5. Émeric Created attachment 412698 [details, diff]
Add ia64 as supported CPU to JSC
(In reply to Pacho Ramos from comment #8) > Created attachment 412670 [details, diff] [details, diff] > 1.patch > > Also try after applying this patch please Patch in attachment 412698 [details, diff] was also required. Still fails early during compile phase. I don't have build.log available at the moment, but can provide it if required. Though I highly doubt that the required bits for ia64 are in WebKit source code. See my attempt at fixing WebKit 2.2.5 (at the time) in [2]... Well, I'm also surprised that PA-RISC was added as a supported platform upstream [1]! IIRC, 64-bit PA-RISC and ia64 are distant relatives. Émeric [1] https://bugs.webkit.org/show_bug.cgi?id=143453 [2] https://bugs.webkit.org/show_bug.cgi?id=129992#c2 Created attachment 412700 [details]
Update webkit-gtk-2.8.5 CMakeOutput.log with 2.patch applied
(In reply to Gilles Dartiguelongue from comment #9) > webkit is not needed for JS but for webviews in "online accounts". [Thanks for clarifying. In the meantime, I've also asked for explanations on Gjs/Seed (well, WebKit) on javascript-list@gnome.org] Wow, isn't this overkill to have two JS runtimes (Spidermonkey for Gjs and WebKit for WebKit-GTK) "just" for webviews? As we can't "avoid" Spidermonkey (since it's required by Gjs, that in turn is used by several GNOME components), isn't there a "Gjs-based" webview alternative in order to rely on a unique JS runtime? IIRC, Yelp (for example) didn't require WebKit-GTK in the past, so probably made use of a different "webview implementation" at the time. Isn't this no more possible nowadays? > This applet is already optional at g-c-c level afaik. g-o-a is mandatory for one GNOME component, but I don't remember whether it's g-c-c or not at the moment. Will look again. Émeric (In reply to Émeric Maschino from comment #14) > Created attachment 412700 [details] > Update webkit-gtk-2.8.5 CMakeOutput.log with 2.patch applied How does the new build.log look? Created attachment 412834 [details]
Updated build.log with 1.patch and 2.patch applied
(In reply to Pacho Ramos from comment #16) > (In reply to Émeric Maschino from comment #14) > > Created attachment 412700 [details] > > Update webkit-gtk-2.8.5 CMakeOutput.log with 2.patch applied > > How does the new build.log look? See attachment 412834 [details]. Build fails because of a missing (C++11) std::is_trivially_default_constructible in gcc 4.7. This was reported upstream and apparently fixed in gcc 4.8 [1], but we're stuck with gcc 4.7 on ia64 at the moment [2]. Émeric [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52702 [2] https://bugs.gentoo.org/show_bug.cgi?id=503838 Yeah, that looks like https://bugs.webkit.org/show_bug.cgi?id=122008 There is a patch in last comment, maybe that one or an adaptation of https://bugs.webkit.org/attachment.cgi?id=212782&action=diff could work for you (In reply to Pacho Ramos from comment #19) > Yeah, that looks like https://bugs.webkit.org/show_bug.cgi?id=122008 > > There is a patch in last comment, maybe that one or an adaptation of > https://bugs.webkit.org/attachment.cgi?id=212782&action=diff could work for > you I'll try this GCC < 4.8.1 hack, but if you look at Source/WTF/wtf/Compiler.h currently in master [1], you'll notice (lines 75-77): #if !GCC_VERSION_AT_LEAST(4, 9, 0) #error "Please use a newer version of GCC. WebKit requires GCC 4.9.0 or newer to compile." #endif Minimum GCC version is set to 4.7.0 for webkit-gtk-2.8.5 at the moment, but time is quickly running out... Émeric [1] https://github.com/WebKit/webkit/blob/master/Source/WTF/wtf/Compiler.h (In reply to Émeric Maschino from comment #20) > I'll try this GCC < 4.8.1 hack, but if you look at Source/WTF/wtf/Compiler.h > currently in master [1], you'll notice (lines 75-77): > > #if !GCC_VERSION_AT_LEAST(4, 9, 0) > #error "Please use a newer version of GCC. WebKit requires GCC 4.9.0 or > newer to compile." > #endif > > Minimum GCC version is set to 4.7.0 for webkit-gtk-2.8.5 at the moment, but > time is quickly running out... > > Émeric > > > [1] https://github.com/WebKit/webkit/blob/master/Source/WTF/wtf/Compiler.h Well, this was even quicker than what I was expecting: back to bug #513888. But this time, Ruby (2.0.0p645) segfaults at Source/JavaScriptCore/offlineasm/transform.rb:202 Émeric (In reply to Émeric Maschino from comment #21) > > Well, this was even quicker than what I was expecting: back to bug #513888. > > But this time, Ruby (2.0.0p645) segfaults at > Source/JavaScriptCore/offlineasm/transform.rb:202 > > Émeric Hacking webkit-gtk-2.8.5.ebuild to force use of /usr/bin/ruby19 interpreter, I was able to go a little bit farther. New error is: /var/tmp/portage/net-libs/webkit-gtk-2.8.5/work/webkitgtk-2.8.5/Source/JavaScriptCore/inspector/JSGlobalObjectConsoleClient.cpp:73:67: error: ‘this’ was not captured for this lambda function Corresponding code is: JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient(InspectorConsoleAgent* consoleAgent) : ConsoleClient() , m_consoleAgent(consoleAgent) { static std::once_flag initializeLogging; std::call_once(initializeLogging, []{ JSGlobalObjectConsoleClient::initializeLogToSystemConsole(); }); } Yet another GCC < 4.8 bug [1]. Hacking and resuming emerge again... Émeric [1] http://stackoverflow.com/questions/4940259/lambdas-require-capturing-this-to-call-static-member-function (In reply to Émeric Maschino from comment #22) > > New error is: > > /var/tmp/portage/net-libs/webkit-gtk-2.8.5/work/webkitgtk-2.8.5/Source/ > JavaScriptCore/inspector/JSGlobalObjectConsoleClient.cpp:73:67: error: ‘this’ > was not captured for this lambda function Fixed, as well as other similar errors in Source/WebCore/Modules/websockets/WorkerThreadableWebSocketChannel.cpp. I'm now stuck with a function disambiguation problem in Source/WebCore/platform/network/soup/ResourceHandleSoup.cpp: void ResourceHandle::sendPendingRequest() { #if ENABLE(WEB_TIMING) m_requestTime = monotonicallyIncreasingTime(); #endif if (d->m_firstRequest.timeoutInterval() > 0) { d->m_timeoutSource.scheduleAfterDelay("[WebKit] ResourceHandle request timeout", [this] { client()->didFail(this, ResourceError::timeoutError(firstRequest().url().string())); cancel(); }, std::chrono::duration_cast<std::chrono::microseconds>(std::chrono::duration<double>(d->m_firstRequest.timeoutInterval())), G_PRIORITY_DEFAULT, nullptr, g_main_context_get_thread_default()); } // Balanced by a deref() in cleanupSoupRequestOperation, which should always run. ref(); d->m_cancellable = adoptGRef(g_cancellable_new()); soup_request_send_async(d->m_soupRequest.get(), d->m_cancellable.get(), sendRequestCallback, this); } g++ fails to determine which overload to call: virtual void WTF::GMainLoopSource::scheduleAfterDelay(const char*, std::function<void()>, std::chrono::microseconds, int, std::function<void()>, GMainContext*) or virtual void WTF::GMainLoopSource::scheduleAfterDelay(const char*, std::function<bool()>, std::chrono::microseconds, int, std::function<void()>, GMainContext*) I don't see what I can do to solve this ambiguity. Is trying to solve all these C++11 problems with gcc 4.7 a dead horse? Émeric (In reply to Émeric Maschino from comment #23) i think trying to fix/workaround the glibc/gcc-4.8+ bug is the only sane path forward for ia64 (In reply to SpanKY from comment #24) > (In reply to Émeric Maschino from comment #23) > > i think trying to fix/workaround the glibc/gcc-4.8+ bug is the only sane > path forward for ia64 Strongly agree, although I fear I lack the skills to help there :-( So, I've stopped trying to fix C++11 issues with gcc-4.7, reworked ruby section to use ruby-1.9 (because of bug #513888), removed nearly all ia64 patches (they seem all obsolete to me; more in a a separate comment) emerged gcc-4.8 and finally successfully built webkit-gtk-2.8 using gcc-4.8. But since glibc was built using gcc-4.7 on my system (because of bug #503838), I'm now hitting bug #513386 for all packages linking against libwebkitgtk-3.0.so (e.g. yelp, evolution, ...), hence still preventing ia64 from updating to >=gnome-3.16. Émeric Created attachment 415770 [details, diff]
Fix webkit-gtk-2.8.5 ia64 build
(In reply to Émeric Maschino from comment #26) > Created attachment 415770 [details, diff] [details, diff] > Fix webkit-gtk-2.8.5 ia64 build OK, I *think* that all ia64-related patches (i.e. webkit-gtk-2.6.0-ia64-platform.patch and webkit-gtk-2.8.1-ia64-malloc.patch) but attached webkit-gtk-2.8.5-fix-ia64-build.patch can be safely removed from webkit-gtk-2.8.5. ebuild. They're completely outdated with current WebKit-GTK architecture. This doesn't mean that WebKit-GTK no more crashes on ia64, though! But if you're running your ia64 kernel configured with CONFIG_IA64_PAGE_SIZE_16KB=y as most (all?) ia64 Linux distributions back at the time, things should be better thanks to fix for WebKit's bug #115502 [1]. Émeric [1] https://bugs.webkit.org/show_bug.cgi?id=115502 > (In reply to Émeric Maschino from comment #23) > > But since glibc was built using gcc-4.7 on my system (because of bug > #503838), I'm now hitting bug #513386 for all packages linking against > libwebkitgtk-3.0.so (e.g. yelp, evolution, ...), hence still preventing ia64 > from updating to >=gnome-3.16. Rebuilding gcc 4.8 with patch from bug #513386 [1], webkit-gtk-2.8 with patched gcc 4.8 and then yelp and evolution (still with ia64 stable gcc 4.7) fixed the problem for me. My ia64 workstation is finally running gnome-3.16.0 :-) Émeric [1] https://bugs.gentoo.org/show_bug.cgi?id=513386#c18 (In reply to Émeric Maschino from comment #27) > > OK, I *think* that all ia64-related patches (i.e. > webkit-gtk-2.6.0-ia64-platform.patch and webkit-gtk-2.8.1-ia64-malloc.patch) > but attached webkit-gtk-2.8.5-fix-ia64-build.patch can be safely removed > from webkit-gtk-2.8.5. ebuild. > > They're completely outdated with current WebKit-GTK architecture. This > doesn't mean that WebKit-GTK no more crashes on ia64, though! But if you're > running your ia64 kernel configured with CONFIG_IA64_PAGE_SIZE_16KB=y as > most (all?) ia64 Linux distributions back at the time, things should be > better thanks to fix for WebKit's bug #115502 [1]. Coincidentally, I just got feedback about the status of WebKit's ia64 [1]. Well, it'll be a long journey before WebKit properly works on ia64 as I'm not a WebKit developer either... Émeric [1] https://bugs.webkit.org/show_bug.cgi?id=129992#c4 Can you please attach and ebuild diff over current ebuild in the tree to ensure we get all the changed that you have tested make it work again for ia64? Thanks Created attachment 416038 [details] Updated webkit-gtk-2.8.5.ebuild to build on ia64 The webkit-gtk-2.8.5-fix-ia64-build.patch referred therein is attachment #415770 [details, diff] Created attachment 416040 [details] Diff between webkit-gtk-2.8.5.ebuild in portage and attachment #416038 [details] (In reply to Pacho Ramos from comment #30) > Can you please attach and ebuild diff over current ebuild in the tree to > ensure we get all the changed that you have tested make it work again for > ia64? > > Thanks Sure, please find attachment #416038 [details] (referring to attachment #415770 [details, diff]) and attachment #416040 [details] for the diff. Note that you probably don't want the reworked Ruby section, as Ruby 1.9 has been marked for removal on October 30th [1], which is problematic as ia64 will be left with no working Ruby implementation [2][3]! Émeric [1] https://bugs.gentoo.org/show_bug.cgi?id=536852 [2] https://bugs.gentoo.org/show_bug.cgi?id=513888 [3] https://bugs.gentoo.org/show_bug.cgi?id=561780 [master 8d2af1c] net-libs/webkit-gtk: Fix ia64, bug #555504 by Émeric Maschino 2 files changed, 26 insertions(+), 5 deletions(-) create mode 100644 net-libs/webkit-gtk/files/webkit-gtk-2.8.5-fix-ia64-build.patch |