Re: [webkit-dev] Vista Install of development tools

2008-03-06 Thread Adam Roben

On Mar 6, 2008, at 1:05 AM, Richard Bailey wrote:



wrt. the page: http://webkit.org/building/tools.html

After several attempts to get cygwin to install correctly in Vista,  
I found I needed to launch setup.exe by right-clicking and choosing  
Run as Administrator


After this, the install worked fine.

Is this the apropriate way to report this?


The best way to report it would be to file a bug on http://bugs.webkit.org/ 
 describing the problem with the website and how what you had to do  
differed from the instructions there. The best way to make sure it  
gets fixed is to make a patch fixing the instructions (the source code  
for our website is kept in the WebKitSite directory of our source  
tree) and attach it to the bug. Thanks!


-Adam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] New autotools build system landed in r28997

2008-03-06 Thread Alp Toker
Alp Toker wrote:
 Q: I'm a WebKit developer. Should I try to keep this build system up to 
 date when I add/remove files from the project?
 
 It would be helpful, but until the transition is complete (ie. the build 
 bot starts using autotools) there's no pressure on anyone outside of the 
 GTK+ port to maintain these files.

We switched the default build system to autotools yesterday. The build 
bot is offline while it gets some necessary updates.

The qmake build is no longer supported for WebKit/GTK+ (and produces 
incorrect installations). Please follow the updated build instructions at

   http://trac.macosforge.org/projects/webkit/wiki/BuildingGtk

It's been a surprising amount of work to switch build system in a 
project of this size and get developers used to the new setup. Thanks a 
to everyone who made this happen.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] https pages crashes WebKit(GTK+DFB) on ARM

2008-03-06 Thread Mike Emmel
What is the gcc version ?
Can you try with the lastest.

On Thu, Mar 6, 2008 at 6:31 AM, Srinivas Rao M Hamse
[EMAIL PROTECTED] wrote:
 Forwarding the message to the list with some more debugging information.

 Hi,


 The backtrace is finally available. From this i i think it is crashing in
 Balloc() function. We have enabled swap, And when the crash happened there
 was ample amount of memory free in the system. This crash is consistently
 reproducible on ARM.

 crash point is at

  JavaScriptCore/kjs/dtoa.cpp:522
  The pointer of freenode is corrupted value.

  (gdb) p freelist[k]
  $2 = (Bigint *) 0x3000
  (gdb) p freelist
  $24 = {0x1bbe30, 0x30303030 repeats 13 times, 0x3000, 0x0}
  (gdb) p rv
  $25 = (Bigint *) 0x3000
  (gdb) p rv-next
  Cannot access memory at address 0x3000
  (gdb) p *rv



  Here is the output of meminfo ofter the crash.

   # cat /proc/meminfo
  MemTotal:73400 kB
 MemFree:  1600 kB
 Buffers: 0 kB
  Cached:   2692 kB
  SwapCached:  29888 kB
  Active:  48352 kB
  Inactive: 6736 kB
  HighTotal:   0 kB
  HighFree:0 kB
  LowTotal:73400 kB
  LowFree:  1600 kB
  SwapTotal: 1953464 kB
 SwapFree:  1794440 kB
  Dirty:   0 kB
  Writeback:   0 kB
  AnonPages:   49020 kB
  Mapped:   1592 kB
  Slab: 2376 kB
  PageTables:568 kB
  NFS_Unstable:0 kB
  Bounce:  0 kB
  CommitLimit:   1990164 kB
  Committed_AS:   219836 kB
  VmallocTotal:   454656 kB
  VmallocUsed:   968 kB
  VmallocChunk:   453688 kB


  Here is the gdb console output [ .. pretty long trace .. i thought it will
 be useful for analysis,  excuse me for that ...]

   # /data/srini/gdb ./GtkLauncher
  GNU gdb 6.6
  Copyright (C) 2006 Free Software Foundation, Inc.
  GDB is free software, covered by the GNU General Public License, and you
 are
  welcome to change it and/or distribute copies of it under certain
 conditions.
  Type show copying to see the conditions.
  There is absolutely no warranty for GDB.  Type show warranty for details.
  This GDB was configured as arm-linux...
  Using host libthread_db library /lib/libthread_db.so.1.
  (gdb) r https://sourceforge.net
  Starting program:
 /home/srinirao/docs/webkit/WebKit-r30790.davinci.directfb/debug_gbuild/Programs/.libs/GtkLauncher
 https://sourceforge.net
  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
  [Thread debugging using libthread_db enabled]
  [New Thread 16384 (LWP 1184)]
  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]


  ===|  DirectFB 1.1.1  |===
   (c) 2001-2007  The DirectFB Organization (directfb.org)
(c) 2000-2004  Convergence (integrated media) GmbH
 

  (*) DirectFB/Core: Single Application Core. (2008-03-06 11:15)
  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
  [New Thread 32769 (LWP 1211)]
  [New Thread 16386 (LWP 1218)]
  (*) Direct/Thread: Running 'VT Switcher' (CRITICAL, 1218)...
  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]

  init_ir_loop
 Inintializing IR
  [New Thread 32771 (LWP 1219)]
  msp430lib_set_params: success
  [New Thread 49156 (LWP 1220)]
  [New Thread 65541 (LWP 1221)]
  [New Thread 81926 (LWP 1222)]
   got DAVINCI_GPIO_IRQ_WAIT ioctl ...
  [New Thread 98311 (LWP 1223)]
  (*) Direct/Thread: Running 'LiRC Input' (INPUT, 1223)...
  (*) DirectFB/Input: LIRC Device 0.2 (directfb.or got DAVINCI_GPIO_IRQ_WAIT
 ioctl ...

 g)

  (!) Direct/Modules: Could not open module directory
 `/home/srinirao/directfb/lib/directfb-1.1-0-pure/gfxdrivers'!
 -- No such file or directory
  (*) DirectFB/Graphics: Generic Software Rasterizer 0.6 (directfb.org)
  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]

 (*) DirectFB/Core/WM: Default 0.3 (directfb.org)
  (*) FBDev/Mode: Testing 720x480 RGB16
 (*) FBDev/Mode: Preparing switch to 720x480 RGB16
  (*) FBDev/Mode: Testing 720x480 RGB16
  (*) FBDev/Mode: Preparin got 

Re: [webkit-dev] https pages crashes WebKit(GTK+DFB) on ARM

2008-03-06 Thread Mike Emmel
Ohh and make sure curl is compiled with ssl support sorry forgot that part.
I was seeing crashes in the old curl driver is ssl was disabled.


On Thu, Mar 6, 2008 at 8:31 AM, Mike Emmel [EMAIL PROTECTED] wrote:
 What is the gcc version ?
  Can you try with the lastest.

  On Thu, Mar 6, 2008 at 6:31 AM, Srinivas Rao M Hamse


 [EMAIL PROTECTED] wrote:
   Forwarding the message to the list with some more debugging information.
  
   Hi,
  
  
   The backtrace is finally available. From this i i think it is crashing in
   Balloc() function. We have enabled swap, And when the crash happened there
   was ample amount of memory free in the system. This crash is consistently
   reproducible on ARM.
  
   crash point is at
  
JavaScriptCore/kjs/dtoa.cpp:522
The pointer of freenode is corrupted value.
  
(gdb) p freelist[k]
$2 = (Bigint *) 0x3000
(gdb) p freelist
$24 = {0x1bbe30, 0x30303030 repeats 13 times, 0x3000, 0x0}
(gdb) p rv
$25 = (Bigint *) 0x3000
(gdb) p rv-next
Cannot access memory at address 0x3000
(gdb) p *rv
  
  
  
Here is the output of meminfo ofter the crash.
  
 # cat /proc/meminfo
MemTotal:73400 kB
   MemFree:  1600 kB
   Buffers: 0 kB
Cached:   2692 kB
SwapCached:  29888 kB
Active:  48352 kB
Inactive: 6736 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:73400 kB
LowFree:  1600 kB
SwapTotal: 1953464 kB
   SwapFree:  1794440 kB
Dirty:   0 kB
Writeback:   0 kB
AnonPages:   49020 kB
Mapped:   1592 kB
Slab: 2376 kB
PageTables:568 kB
NFS_Unstable:0 kB
Bounce:  0 kB
CommitLimit:   1990164 kB
Committed_AS:   219836 kB
VmallocTotal:   454656 kB
VmallocUsed:   968 kB
VmallocChunk:   453688 kB
  
  
Here is the gdb console output [ .. pretty long trace .. i thought it will
   be useful for analysis,  excuse me for that ...]
  
 # /data/srini/gdb ./GtkLauncher
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
   are
welcome to change it and/or distribute copies of it under certain
   conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for 
 details.
This GDB was configured as arm-linux...
Using host libthread_db library /lib/libthread_db.so.1.
(gdb) r https://sourceforge.net
Starting program:
   
 /home/srinirao/docs/webkit/WebKit-r30790.davinci.directfb/debug_gbuild/Programs/.libs/GtkLauncher
   https://sourceforge.net
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 1184)]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
  
  
===|  DirectFB 1.1.1  |===
 (c) 2001-2007  The DirectFB Organization (directfb.org)
  (c) 2000-2004  Convergence (integrated media) GmbH
   
  
(*) DirectFB/Core: Single Application Core. (2008-03-06 11:15)
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[New Thread 32769 (LWP 1211)]
[New Thread 16386 (LWP 1218)]
(*) Direct/Thread: Running 'VT Switcher' (CRITICAL, 1218)...
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
  
init_ir_loop
   Inintializing IR
[New Thread 32771 (LWP 1219)]
msp430lib_set_params: success
[New Thread 49156 (LWP 1220)]
[New Thread 65541 (LWP 1221)]
[New Thread 81926 (LWP 1222)]
 got DAVINCI_GPIO_IRQ_WAIT ioctl ...
[New Thread 98311 (LWP 1223)]
(*) Direct/Thread: Running 'LiRC Input' (INPUT, 1223)...
(*) DirectFB/Input: LIRC Device 0.2 (directfb.or got DAVINCI_GPIO_IRQ_WAIT
   ioctl ...
  
   g)
  
(!) Direct/Modules: Could not open module directory
   `/home/srinirao/directfb/lib/directfb-1.1-0-pure/gfxdrivers'!
   -- No such 

[webkit-dev] Windows build error during link

2008-03-06 Thread Mike McMullen
I have run 'build-webkit --clean' and simply deleted the WebKitBuild
subdirectory, but still get the link errors posted above.  Is this
sufficient to remove any lingering failed build information that may be
influencing my builds now?
 
I can only assume the project is building for everyone else so my issue must
be related to my build environment.  Is there any additional items that need
to be removed (ie generated/pre-compiled code)?
 
-Mike
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] many tests failing during run-webkit-tests in Apple Windows

2008-03-06 Thread Bailey, Richard
Is this the expected current state of the build, or is it a problem with my 
build/test-run?

Is there a site/tool that can show me the current test state of the repository?

Here is an example of the failures:

Tests where results did not match expected results:
css1/basic/class_as_selector.htmlfile:///c:\cygwin\WebKit\WebKit\LayoutTests\css1\basic\class_as_selector.html

expectedfile:///C:\cygwin\tmp\layout-test-results\css1\basic\class_as_selector-expected.txt
   
actualfile:///C:\cygwin\tmp\layout-test-results\css1\basic\class_as_selector-actual.txt
   
diffsfile:///C:\cygwin\tmp\layout-test-results\css1\basic\class_as_selector-diffs.txt
css1/basic/comments.htmlfile:///c:\cygwin\WebKit\WebKit\LayoutTests\css1\basic\comments.html
  
expectedfile:///C:\cygwin\tmp\layout-test-results\css1\basic\comments-expected.txt

actualfile:///C:\cygwin\tmp\layout-test-results\css1\basic\comments-actual.txt

diffsfile:///C:\cygwin\tmp\layout-test-results\css1\basic\comments-diffs.txt
css1/basic/containment.htmlfile:///c:\cygwin\WebKit\WebKit\LayoutTests\css1\basic\containment.html

expectedfile:///C:\cygwin\tmp\layout-test-results\css1\basic\containment-expected.txt
 
actualfile:///C:\cygwin\tmp\layout-test-results\css1\basic\containment-actual.txt
 
diffsfile:///C:\cygwin\tmp\layout-test-results\css1\basic\containment-diffs.txt
css1/basic/contextual_selectors.htmlfile:///c:\cygwin\WebKit\WebKit\LayoutTests\css1\basic\contextual_selectors.html
  
expectedfile:///C:\cygwin\tmp\layout-test-results\css1\basic\contextual_selectors-expected.txt

actualfile:///C:\cygwin\tmp\layout-test-results\css1\basic\contextual_selectors-actual.txt

diffsfile:///C:\cygwin\tmp\layout-test-results\css1\basic\contextual_selectors-diffs.txt
css1/basic/grouping.htmlfile:///c:\cygwin\WebKit\WebKit\LayoutTests\css1\basic\grouping.html
  
expectedfile:///C:\cygwin\tmp\layout-test-results\css1\basic\grouping-expected.txt

actualfile:///C:\cygwin\tmp\layout-test-results\css1\basic\grouping-actual.txt

diffsfile:///C:\cygwin\tmp\layout-test-results\css1\basic\grouping-diffs.txt
css1/basic/id_as_selector.htmlfile:///c:\cygwin\WebKit\WebKit\LayoutTests\css1\basic\id_as_selector.html
  
expectedfile:///C:\cygwin\tmp\layout-test-results\css1\basic\id_as_selector-expected.txt
  
actualfile:///C:\cygwin\tmp\layout-test-results\css1\basic\id_as_selector-actual.txt
  
diffsfile:///C:\cygwin\tmp\layout-test-results\css1\basic\id_as_selector-diffs.txt


@@ -1,12 +1,12 @@
-layer at (0,0) size 800x600
-  RenderView at (0,0) size 800x600
-layer at (0,0) size 800x600
-  RenderBlock {HTML} at (0,0) size 800x600
-RenderBody {BODY} at (8,8) size 784x584 [bgcolor=#CC]
-  RenderBlock {P} at (0,0) size 784x18
-RenderText {#text} at (0,0) size 355x18
+layer at (0,0) size 785x615
+  RenderView at (0,0) size 785x600
+layer at (0,0) size 785x615
+  RenderBlock {HTML} at (0,0) size 785x615
+RenderBody {BODY} at (8,8) size 769x599 [bgcolor=#CC]
+  RenderBlock {P} at (0,0) size 769x21
+RenderText {#text} at (0,0) size 355x20




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] many tests failing during run-webkit-tests in Apple Windows

2008-03-06 Thread Eric Seidel
You may be missing the required fonts.  (And thus be getting the wrong
metrics for text runs).  Safari bundles some fonts with it.  The Apple
developers all have these custom fonts installed on their system.

Other external contributers use some special instructions to get the
fonts step correctly.  See Qt's instructions:
http://trac.macosforge.org/projects/webkit/wiki/QtWebKitContrib

-eric

On Thu, Mar 6, 2008 at 10:32 AM, Bailey, Richard [EMAIL PROTECTED] wrote:


 Is this the expected current state of the build, or is it a problem with my
 build/test-run?

 Is there a site/tool that can show me the current test state of the
 repository?

 Here is an example of the failures:
 Tests where results did not match expected results:
  css1/basic/class_as_selector.html expected actual diffs
  css1/basic/comments.html expected actual diffs
  css1/basic/containment.html expected actual diffs
  css1/basic/contextual_selectors.html expected actual diffs
  css1/basic/grouping.html expected actual diffs
  css1/basic/id_as_selector.html expected actual diffs


 @@ -1,12 +1,12 @@
 -layer at (0,0) size 800x600
 -  RenderView at (0,0) size 800x600
 -layer at (0,0) size 800x600
 -  RenderBlock {HTML} at (0,0) size 800x600
 -RenderBody {BODY} at (8,8) size 784x584 [bgcolor=#CC]
 -  RenderBlock {P} at (0,0) size 784x18
 -RenderText {#text} at (0,0) size 355x18
 +layer at (0,0) size 785x615
 +  RenderView at (0,0) size 785x600
 +layer at (0,0) size 785x615
 +  RenderBlock {HTML} at (0,0) size 785x615
 +RenderBody {BODY} at (8,8) size 769x599 [bgcolor=#CC]
 +  RenderBlock {P} at (0,0) size 769x21
 +RenderText {#text} at (0,0) size 355x20




 ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Windows build error during link

2008-03-06 Thread David Kilzer
Have you tried setting the build configuration when running build-webkit?  For
example:

build-webkit --clean --debug

Or:

build-webkit --clean --release

See also the set-webkit-configuration script.

Dave


Mike McMullen [EMAIL PROTECTED] wrote:

 I have run 'build-webkit --clean' and simply deleted the WebKitBuild
 subdirectory, but still get the link errors posted above.  Is this
 sufficient to remove any lingering failed build information that may be
 influencing my builds now?
  
 I can only assume the project is building for everyone else so my issue must
 be related to my build environment.  Is there any additional items that need
 to be removed (ie generated/pre-compiled code)?
  
 -Mike

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] many tests failing during run-webkit-tests in Apple Windows

2008-03-06 Thread Bailey, Richard
Thanks Eric,

$ svn co svn://labs.trolltech.com/svn/webkit/testfonts
svn: Can't connect to host 'labs.trolltech.com': Connection refused

Is this trolltech/svn  down or restricted for read access?

Thanks for the help,
Richard


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Seidel
Sent: Thursday, March 06, 2008 10:41 AM
To: Bailey, Richard
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] many tests failing during run-webkit-tests in Apple 
Windows

You may be missing the required fonts.  (And thus be getting the wrong
metrics for text runs).  Safari bundles some fonts with it.  The Apple
developers all have these custom fonts installed on their system.

Other external contributers use some special instructions to get the
fonts step correctly.  See Qt's instructions:
http://trac.macosforge.org/projects/webkit/wiki/QtWebKitContrib

-eric

On Thu, Mar 6, 2008 at 10:32 AM, Bailey, Richard [EMAIL PROTECTED] wrote:


 Is this the expected current state of the build, or is it a problem with my
 build/test-run?

 Is there a site/tool that can show me the current test state of the
 repository?

 Here is an example of the failures:
 Tests where results did not match expected results:
  css1/basic/class_as_selector.html expected actual diffs
  css1/basic/comments.html expected actual diffs
  css1/basic/containment.html expected actual diffs
  css1/basic/contextual_selectors.html expected actual diffs
  css1/basic/grouping.html expected actual diffs
  css1/basic/id_as_selector.html expected actual diffs


 @@ -1,12 +1,12 @@
 -layer at (0,0) size 800x600
 -  RenderView at (0,0) size 800x600
 -layer at (0,0) size 800x600
 -  RenderBlock {HTML} at (0,0) size 800x600
 -RenderBody {BODY} at (8,8) size 784x584 [bgcolor=#CC]
 -  RenderBlock {P} at (0,0) size 784x18
 -RenderText {#text} at (0,0) size 355x18
 +layer at (0,0) size 785x615
 +  RenderView at (0,0) size 785x600
 +layer at (0,0) size 785x615
 +  RenderBlock {HTML} at (0,0) size 785x615
 +RenderBody {BODY} at (8,8) size 769x599 [bgcolor=#CC]
 +  RenderBlock {P} at (0,0) size 769x21
 +RenderText {#text} at (0,0) size 355x20




 ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Windows build error during link

2008-03-06 Thread Brent Fulgham

Hi Mike,

I'm really confused by these error messages.  It looks like these  
indicate problems with C++ exception handling:



LINK : warning LNK4044: unrecognized option '/dynamicbase'; ignored
   Creating library c:\cygwin\home\mike\WebKit\WebKitBuild\lib 
\WebKit.lib and ob

ject c:\cygwin\home\mike\WebKit\WebKitBuild\lib\WebKit.exp
WebCore_debug.lib(RenderLayer.obj) : error LNK2019: unresolved  
external symbol 
__declspec(dllimport) public: void __thiscall  
std::exception::_Raise(void)const
 ([EMAIL PROTECTED]@std@@QBEXXZ) referenced in function  
struct std::pair
class WebCore::RenderLayer * *,int __cdecl  
std::get_temporary_bufferclass Web
Core::RenderLayer *(int) (?? 
[EMAIL PROTECTED]@WebCore@@@std

@@[EMAIL PROTECTED]@WebCore@@[EMAIL PROTECTED]@[EMAIL PROTECTED])
WebCore_debug.lib(CanvasGradient.obj) : error LNK2001: unresolved  
external symbo
l __declspec(dllimport) public: void __thiscall  
std::exception::_Raise(void)con

st  ([EMAIL PROTECTED]@std@@QBEXXZ)
WebCore_debug.lib(RenderLayer.obj) : error LNK2019: unresolved  
external symbol 
__declspec(dllimport) public: __thiscall  
std::exception::exception(char const *,
int) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@Z) referenced in function  
public: __thi
scall std::bad_alloc::bad_alloc(char const *) (?? 
[EMAIL PROTECTED]@@[EMAIL PROTECTED]@Z)
WebCore_debug.lib(CanvasGradient.obj) : error LNK2001: unresolved  
external symbo
l __declspec(dllimport) public: __thiscall  
std::exception::exception(char const

 *,int) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@Z)



I also don't see anything that indicates that WebCore actually built.   
If I recall correctly, I remember seeing an error message about a  
conflict with the standard C library linked to the application.  I  
don't see this on my system, so I wonder if something is misconfigured.


Can you remind me what you are building with (Visual Studio Express?  
Visual Studio Professional?), and if you have installed the Platform  
SDK and have registered the Platform SDK with your development  
environment.


Thanks,

-Brent

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev