Bug 14744 - Cross-compilation broken by recent pcre change
Summary: Cross-compilation broken by recent pcre change
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 523.x (Safari 3)
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-24 03:55 PDT by Koen Kooi
Modified: 2011-06-13 23:06 PDT (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Koen Kooi 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.
Comment 1 Koen Kooi 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
Comment 2 Koen Kooi 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
Comment 3 David Kilzer (:ddkilzer) 2008-01-10 10:25:47 PST 
Is this still an issue?  See also Bug 16818.
Comment 4 Gavin Barraclough 2011-06-13 23:06:13 PDT 
We no longer use PCRE, I don't believe this bug can still be live.