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

[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
 __cdecl  
std::get_temporary_bufferCore::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

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

[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

[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

[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

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

[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.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] Windows build error during link

[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

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

[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 , 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)...
>  >  (*) 

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

[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 , 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/Mod

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

[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] Vista Install of development tools

[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  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