WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED INVALID
14744
Cross-compilation broken by recent pcre change
https://bugs.webkit.org/show_bug.cgi?id=14744
Summary
Cross-compilation broken by recent pcre change
Koen Kooi
Reported
2007-07-24 03:55:36 PDT
It looks like
r24411
introduced running the just built 'dftables', which of course doesn't work when crosscompiling x86->arm, since my opteron chokes on armv5te instructions. The error echo "#include <string.h>" > /data/build/koen/OE/build/tmp/angstrom/work/armv5te-angstrom-linux-gnueabi/webkit-0.0+svn20070724-r1/WebKitBuilds/Debug//WebCore/tmp/DocTypeStrings.cpp && gperf -CEot -L ANSI-C -k '*' -N findDoctypeEntry -F ,PubIDInfo::eAlmostStandards,PubIDInfo::eAlmostStandards < /data/build/koen/OE/build/tmp/angstrom/work/armv5te-angstrom-linux-gnueabi/webkit-0.0+svn20070724-r1/WebCore/html/DocTypeStrings.gperf >> /data/build/koen/OE/build/tmp/angstrom/work/armv5te-angstrom-linux-gnueabi/webkit-0.0+svn20070724-r1/WebKitBuilds/Debug//WebCore/tmp/DocTypeStrings.cpp/data/build/koen/OE/build/tmp/angstrom/work/armv5te-angstrom-linux-gnueabi/webkit-0.0+svn20070724-r1/WebKitBuilds/Debug/JavaScriptCore/pcre/tmp/dftables tmp/chartables.c/data/build/koen/OE/build/tmp/angstrom/work/armv5te-angstrom-linux-gnueabi/webkit-0.0+svn20070724-r1/WebKitBuilds/Debug/JavaScriptCore/pcre/tmp/dftables: /data/build/koen/OE/build/tmp/angstrom/work/armv5te-angstrom-linux-gnueabi/webkit-0.0+svn20070724-r1/WebKitBuilds/Debug/JavaScriptCore/pcre/tmp/dftables: cannot execute binary filemake[1]: *** [tmp/chartables.c] Error 126 Could this be changes to run an external dftables (e.g. dftables from x86 pcre) or back out the offending cset? WebkitGdk did work brilliantly on my arm devices before this cset.
Attachments
Add attachment
proposed patch, testcase, etc.
Koen Kooi
Comment 1
2007-07-24 08:23:02 PDT
As I said in the starting comment: "WebkitGdk did work brilliantly on my arm devices before this cset." So tagging it with 'QT' is useless
Koen Kooi
Comment 2
2007-07-25 03:19:49 PDT
I worked around this with: --- packages/webkit/webkit/WebKit.pro 63fd1bd947de2d3abe6a011685e6173bf0a804e1 +++ packages/webkit/webkit/WebKit.pro c4db9377c267835f4ec934a4d53207e26c25b99c @@ -1,9 +1,8 @@ SUBDIRS += \ TEMPLATE = subdirs CONFIG += ordered !gdk-port:CONFIG += qt-port qt-port:SUBDIRS += WebKitQt/Plugins SUBDIRS += \ - JavaScriptCore/pcre/dftables.pro \ WebCore \ JavaScriptCore/kjs/testkjs.pro and doing cd ${S}/JavaScriptCore/pcre ${BUILD_CC} dftables.c -o dftables -I. -I../wtf cp dftables ${S}/WebKitBuilds/Debug/JavaScriptCore/pcre/tmp/ before starting (q)make
David Kilzer (:ddkilzer)
Comment 3
2008-01-10 10:25:47 PST
Is this still an issue? See also
Bug 16818
.
Gavin Barraclough
Comment 4
2011-06-13 23:06:13 PDT
We no longer use PCRE, I don't believe this bug can still be live.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug