pushed upstream as https://bugs.webkit.org/show_bug.cgi?id=114978)
Seems to fix xombrero/surf crashes on amd64, and seems to magically make
webkit sort-of usable (ie dead-slow, but js seems to work) on powerpc.
(symptom : ** Message: console message: undefined @0: RangeError: Maximum
call stack size exceeded.)
Note : webkit still fails to build on mips64* and hppa. sigh.
ok jasper@
- add ruby to BDEPS. Webkit build system now uses autohell, python, ruby and perl \o/
- set MODRUBY_REV = 1.8 on sparc64 since 1.9 is broken there
- disable WebKit2 support, it needs shm_open()/shm_unlink()
- switch from gstreamer-0.10 to gstreamer1
- force-disable JIT/ASSEMBLER on non-jit archs, builds fails otherwise (bug #113638)
- only build NumberPrototype.cpp with -O0 on sparc64, not the damn whole thing
- use -Wl,--relax on ppc otherwise linking fails
- move some patches around since JavaScriptCore/wtf moved to WTF/wtf
- dont uselessly rerun make within make during install, gmake blows
- blindly backport upstream r144077 to fix mips64 build
- backport bits of #103128 & r145551 to fix powerpc build
- backport r147967 & more to fix bashisms in configure
- bug #109932 forced the use of gcc >= 4.7 or clang >= 3.0, but this is
only for WebKit2 so loosen the check atm
Tested working fine on amd64 & i386, went in bulk builds, known broken
at runtime on ppc (being worked on. or not.) should build on mips64el
(and maybe even run!) and sparc64 (wont run! ever! nothing new here..),
but 'someone' will care about the poor exotic archs and fix'em, right ?
After too much prodding from the gnome maintainers who desperately need it
on the whole gstreamer gang which are only uses by web browsers to
display audio/video.
So remove RUN_DEPENDS, it'll be explicitely added to webkit browsers
with a small comment so that maintainers of such browsers can decide
which gstreamer dependencies they need/want.
ok landry@ (maintainer)
The situation is this: even when we --disable-gtk-doc, if gtk-doc is
actually installed at configure stage, tools like gtkdoc-rebase will be
picked up and run during the install target. That is bad because the
gtk-doc package may have been removed by then, especially during dpb(1)
bulks (we explicitely disable support for it so why should it stay...).
So for now, let's add the following env to configure whenever we use
--disable-gtk-doc, until a bettersolution is found...
CONFIGURE_ENV +=ac_cv_path_GTKDOC_CHECK="" \
ac_cv_path_GTKDOC_REBASE="" \
ac_cv_path_GTKDOC_MKPDF=""
- disable static libs, shrinks package size by a factor 3
- now depends on geoclue for geolocation purposes (of course its up to
the browsers to enable the feature or not..)
- simplify Makefile/FLAVORS/SHARED_LIBS
- fold most of the PFRAGs to PLIST by using variables
- remove patch-Source_JavaScriptCore_runtime_JSValue_h, seems it was
added for sparc64 but now it breaks the build there, and noone has been
able to justify the addition of that patch. Without it, GtkLauncher
shows simple html websites on sparc64 and crashes as soon as some js is
involved, but thats not much different from before
- remove patch-Source_JavaScriptCore_wtf_text_StringHash_h &
patch-Source_JavaScriptCore_wtf_text_StringImpl_cpp, replaced by
patch-Source_JavaScriptCore_runtime_UString_h for mips64/sparc64
- add patch-Source_JavaScriptCore_wtf_NumberOfCores_cpp for #82585
tested on i386/amd64 by several, amd64 bulk build, ppc & sparc64 testing
by myself. mips64el in the works..
ok ajacoutot@
- switch to .tar.xz distfile
- bump libjavascriptgtk major
- backport a commit from upstream bz #68314, fixes issues on twitter
tested by aja@/pstumpf@/kili@ on amd64 & myself on i386/ppc.
Allow setting max-conns and max-conns-per-host without overwriting the
given values, which supposedly fixes the file descriptor starvation
issue people were experiencing..
See https://bugs.webkit.org/show_bug.cgi?id=64355 for details.
from and after constant prodding by marco@
