[MacOSX] Why GWT ships its own WebKit & Co Frameworks?

24 views
Skip to first unread message

Alexander Mitin

unread,
Feb 13, 2007, 1:56:03 PM2/13/07
to Google Web Toolkit Contributors
Hello.

I suppose that WebKit modified to be able to get some internal info.
May be we can find another way to get such info and compile GWT
against WebKit system framework? I'm asking because it seems that I
experienced a conflict between system WebKit and GWT's WebKit
frameworks:

dyld: Symbol not found: _objc_getClass
Referenced from: /Users/mitin_aa/Documents/
workspace/.metadata/.plugins/org.eclipse.pde.core/New_configuration/
org.eclipse.osgi/bundles/102/1/.cp/libswt-webkit-carbon-3232.jnilib
Expected in: /Users/mitin_aa/gwt/gwt-mac-1.3.3/Frameworks/
WebKit.framework/Versions/A/WebKit


--
Alexander Mitin

Alexander Mitin

unread,
Feb 13, 2007, 2:01:38 PM2/13/07
to Google Web Toolkit Contributors
Hmm... seems that Google Groups stripped "[MacOSX]" from subject.
My question related to MacOSX as you're already guessed :-)

--
Alexander Mitin

Jason Essington

unread,
Feb 13, 2007, 2:02:08 PM2/13/07
to Google-Web-Tool...@googlegroups.com
I think that the current system WebKit library is incapable of
working with GWT (maybe it doesn't expose the necessary APIs)

At any rate, the supplied webkit includes the ultra-cool DOM
inspector that I find indispensable.

Not sure where your conflict came from though, I've been using GWT on
OS X since before there was an OS X build and haven't had a problem ...

I also tend to have a dozen or so nightly builds of WebKit lying
around too ...

-jason

Alexander Mitin

unread,
Feb 13, 2007, 2:07:48 PM2/13/07
to Google Web Toolkit Contributors
Jason,

I'm writing an Eclipse plugin that uses GWT classes. All works fine
until Eclipse wants to use its own classes which requires WebKit. So,
it tries to load system WebKit and crashes with error from dynamic
linker.

Kelly Norton

unread,
Feb 13, 2007, 2:32:46 PM2/13/07
to Google-Web-Tool...@googlegroups.com
The primary difference between the WebKit that ships with GWT and the system WebKit is that in our version all symbols from JavaScriptCore have been exported. JavaScriptCore currently ships as a private framework within WebKIt and they export only the symbols they need to expose (very few). We needed to operate a little deeper within JavaScriptCore than was possible. Another very relevant data point is that the WebKit that we ship encodes its install path as /System/Library/Frameworks/WebKit.framework/... The main reason for this is that if other shared libraries are loaded into the process that depend on WebKit, we have to make sure our WebKit gets loaded otherwise two separate webkit's will get mapped ... which is bad. We didn't do this in the first RC and InputManagers like Creammonkey caused all sorts of problems because they caused system WebKit to load on top of our own build.

As you might imagine, this is going to be painfully problematic in creating an eclipse plugin because you pretty much have to be running eclipse on our modified version of SWT. It is possible that if you could load our WebKit before you load swt's jni lib (which will issue a load command for system webkit), but you would likely still have problems since we have slightly modified code to handle a number of other little issues that exist in SWT's binding of WebKit.

I've heard some rumors in WebKit land that they are considering exporting JavaScriptCore as a public framework at some point. We're hoping sooner than later since that would allow us to use the System WebKit without hassle (and we would be able to make the OS X build for GWT about half its current size).

/kel

Alexander Mitin

unread,
Feb 14, 2007, 10:28:52 AM2/14/07
to Google Web Toolkit Contributors
Reposting my yesterday message (tweaked a little :) ) because I still
can't see it here.

Kelly,

Thanks for a good explanation.
Does system JavaScriptCode shared library exports all of symbols
needed? I understand that we can't link against JSC directly because
it is a subframework of WebKit. But all code we needed would be in
process' memory as we loaded WebKit framework.
So what if we make a hack and bind code manually (smth like
LoadLibrary/GetProcAddress of Windows land)?

Scott Blum

unread,
Feb 14, 2007, 3:25:46 PM2/14/07
to Google-Web-Tool...@googlegroups.com
On 2/14/07, Alexander Mitin <alexand...@gmail.com> wrote:
> Does system JavaScriptCode shared library exports all of symbols
> needed? I understand that we can't link against JSC directly because
> it is a subframework of WebKit. But all code we needed would be in
> process' memory as we loaded WebKit framework.
> So what if we make a hack and bind code manually (smth like
> LoadLibrary/GetProcAddress of Windows land)?

Kelly and I looked into ways of doing this and could not get past the
dead ends we ran into. The problem is that WebKit simply needs far
fewer (and different) symbols than we need, because we're hitting up
the JS engine directly at an extremely low level. And in the public
distros, they strip out the symbol information (required to do the
runtime link) for any symbols WebKit does need. So while the method
implementations we need exist in the binary, there is simply no
symbolic information we can use to find them.

But if anyone can solve this problem, it would be friggin' awesome.

Scott

Alexander Mitin

unread,
Feb 17, 2007, 2:01:24 PM2/17/07
to Google Web Toolkit Contributors
Hello.

I've spent some time in research and it seems that symbols are not
stripped from JSC but put in private scope. All symbols from text
section of JSC library can be seen by otool -tV (I've attached
symbols.zip file with demangled symbols). We need to figure out what
symbols do we need and what of them can be found in text section of
JSC.
Next task is how to bind symbols into gwt libs. We may try to make it
manually at run-time. But if I got it right the sub-framework under
umbrella framework allows to link against it for any other sub-
framework (neighbor). Next, any sub-framework may allow to certain
(defined at compile-time) dylib to link against this sub-framework. So
what if we write some "proxy" sub-framework of WebKit framework which
allows us to get private symbols from JSC?

Actually I'm working for Instantiations and the "Eclipse plugin" I'm
writing is GWT Designer for Mac. :-)
And frameworks conflict becomes a real showstopper for us. :(

On 14 фев, 23:25, "Scott Blum" <sco...@google.com> wrote:

Scott Blum

unread,
Feb 17, 2007, 9:34:24 PM2/17/07
to Google-Web-Tool...@googlegroups.com
On 2/17/07, Alexander Mitin <alexand...@gmail.com> wrote:
> Next task is how to bind symbols into gwt libs. We may try to make it
> manually at run-time. But if I got it right the sub-framework under
> umbrella framework allows to link against it for any other sub-
> framework (neighbor). Next, any sub-framework may allow to certain
> (defined at compile-time) dylib to link against this sub-framework. So
> what if we write some "proxy" sub-framework of WebKit framework which
> allows us to get private symbols from JSC?

Hi Alexander,

I'm really glad you're looking into this, and I hope your research in
this area will bear fruit, because we would be as anxious as you to
not have to ship WebKit. But one thing I must point out with the
proxy framework idea is this: whatever solution we come up with needs
to be able to run without modifying the user's system. That is, if
the user was required to install a proxy framework into their system
frameworks folders, that wouldn't be a good thing. We would really
like it to continue to run from within the user's GWT installation
folders.

Scott

Alexander Mitin

unread,
Feb 19, 2007, 4:36:36 PM2/19/07
to Google Web Toolkit Contributors
Yes, you're right.. If we even get "proxy framework" working I think
the user will hardly allow us to modify system.
But I can't imagine where to find "vtable for JSObject", linker needs
this (among other symbols) while trying to link against system
WebKit...
I think I'll go to use GWT's SWT in Eclipse... Sad, but it is more
clear way to go.

On Feb 18, 05:34, "Scott Blum" <sco...@google.com> wrote:

--
Alexander Mitin

Reply all
Reply to author
Forward
0 new messages