26293 2009-06-10 09:25:13 -0700 Current svn Qt webkit fails to compile even after fixing bug #26289 2009-09-07 10:29:48 -0700 1 1 1 Unclassified WebKit WebKit Qt 528+ (Nightly build) Other OS X 10.5 RESOLVED FIXED P2 Normal --- 0 bero webkit-unassigned jhaygood laszlo.gombos mrowe pfeldman vestbo oldest_to_newest 125141 0 bero 2009-06-10 09:25:13 -0700 After fixing bug #26289, Qt WebKit build barfs during final linkage: obj/release/JSONObject.o: In function `WebCore::JSONObject::scriptObject() const': JSONObject.cpp:(.text._ZNK7WebCore10JSONObject12scriptObjectEv+0x0): multiple definition of `WebCore::JSONObject::scriptObject() const' obj/release/JSONObject.o:JSONObject.cpp:(.text._ZNK7WebCore10JSONObject12scriptObjectEv+0x0): first defined here obj/release/JSONObject.o: In function `WebCore::JSONObject::set(char const*, bool)': JSONObject.cpp:(.text._ZN7WebCore10JSONObject3setEPKcb+0x0): multiple definition of `WebCore::JSONObject::set(char const*, bool)' obj/release/JSONObject.o:JSONObject.cpp:(.text._ZN7WebCore10JSONObject3setEPKcb+0x0): first defined here obj/release/JSONObject.o: In function `WebCore::JSONObject::set(char const*, int)': JSONObject.cpp:(.text._ZN7WebCore10JSONObject3setEPKci+0x0): multiple definition of `WebCore::JSONObject::set(char const*, int)' obj/release/JSONObject.o:JSONObject.cpp:(.text._ZN7WebCore10JSONObject3setEPKci+0x0): first defined here obj/release/JSONObject.o: In function `WebCore::JSONObject::set(char const*, long long)': JSONObject.cpp:(.text._ZN7WebCore10JSONObject3setEPKcx+0x0): multiple definition of `WebCore::JSONObject::set(char const*, long long)' obj/release/JSONObject.o:JSONObject.cpp:(.text._ZN7WebCore10JSONObject3setEPKcx+0x0): first defined here obj/release/JSONObject.o: In function `WebCore::JSONObject::set(char const*, double)': JSONObject.cpp:(.text._ZN7WebCore10JSONObject3setEPKcd+0x0): multiple definition of `WebCore::JSONObject::set(char const*, double)' obj/release/JSONObject.o:JSONObject.cpp:(.text._ZN7WebCore10JSONObject3setEPKcd+0x0): first defined here obj/release/JSONObject.o: In function `WebCore::JSONObject::set(char const*, WebCore::String const&)': JSONObject.cpp:(.text._ZN7WebCore10JSONObject3setEPKcRKNS_6StringE+0x0): multiple definition of `WebCore::JSONObject::set(char const*, WebCore::String const&)' obj/release/JSONObject.o:JSONObject.cpp:(.text._ZN7WebCore10JSONObject3setEPKcRKNS_6StringE+0x0): first defined here obj/release/JSONObject.o: In function `WebCore::JSONObject::set(char const*, WebCore::ScriptObject const&)': JSONObject.cpp:(.text._ZN7WebCore10JSONObject3setEPKcRKNS_12ScriptObjectE+0x0): multiple definition of `WebCore::JSONObject::set(char const*, WebCore::ScriptObject const&)' obj/release/JSONObject.o:JSONObject.cpp:(.text._ZN7WebCore10JSONObject3setEPKcRKNS_12ScriptObjectE+0x0): first defined here obj/release/JSONObject.o: In function `WebCore::JSONObject::set(WebCore::String const&, WebCore::String const&)': JSONObject.cpp:(.text._ZN7WebCore10JSONObject3setERKNS_6StringES3_+0x0): multiple definition of `WebCore::JSONObject::set(WebCore::String const&, WebCore::String const&)' obj/release/JSONObject.o:JSONObject.cpp:(.text._ZN7WebCore10JSONObject3setERKNS_6StringES3_+0x0): first defined here obj/release/JSONObject.o: In function `WebCore::JSONObject::JSONObject(JSC::ExecState*)': JSONObject.cpp:(.text._ZN7WebCore10JSONObjectC2EPN3JSC9ExecStateE+0x0): multiple definition of `WebCore::JSONObject::JSONObject(JSC::ExecState*)' obj/release/JSONObject.o:JSONObject.cpp:(.text._ZN7WebCore10JSONObjectC2EPN3JSC9ExecStateE+0x0): first defined here obj/release/JSONObject.o: In function `WebCore::JSONObject::set(char const*, WebCore::JSONObject const&)': JSONObject.cpp:(.text._ZN7WebCore10JSONObject3setEPKcRKS0_+0x0): multiple definition of `WebCore::JSONObject::set(char const*, WebCore::JSONObject const&)' obj/release/JSONObject.o:JSONObject.cpp:(.text._ZN7WebCore10JSONObject3setEPKcRKS0_+0x0): first defined here obj/release/JSONObject.o: In function `WebCore::JSONObject::JSONObject(JSC::ExecState*)': JSONObject.cpp:(.text._ZN7WebCore10JSONObjectC1EPN3JSC9ExecStateE+0x0): multiple definition of `WebCore::JSONObject::JSONObject(JSC::ExecState*)' obj/release/JSONObject.o:JSONObject.cpp:(.text._ZN7WebCore10JSONObjectC1EPN3JSC9ExecStateE+0x0): first defined here obj/release/JSONObject.o: In function `WebCore::JSONObject::createNew(JSC::ExecState*)': JSONObject.cpp:(.text._ZN7WebCore10JSONObject9createNewEPN3JSC9ExecStateE+0x0): multiple definition of `WebCore::JSONObject::createNew(JSC::ExecState*)' obj/release/JSONObject.o:JSONObject.cpp:(.text._ZN7WebCore10JSONObject9createNewEPN3JSC9ExecStateE+0x0): first defined here collect2: ld returned 1 exit status make[1]: *** [../lib/libQtWebKit.so.4.5.2] Error 1 125683 1 jhaygood 2009-06-13 15:42:41 -0700 *** Bug 26378 has been marked as a duplicate of this bug. *** 125684 2 jhaygood 2009-06-13 15:44:17 -0700 This is because of a way the Qt build system works. The object files for JavaScriptCore and WebCore are output into the same directory. Both WebCore and JavaScriptCore have a "JSONObject.cpp" which gets built into a "JSONObject.<objectext>" so whichever one gets compiled last is the one that gets linked in. 125687 3 mrowe 2009-06-13 16:01:47 -0700 It's not even clear to me why WebCore::JSONObject exists, or why it's name refers to JSON. It seems to be nothing more than a wrapper around a ScriptObject, and has no relationship to JSON support. ISTM that a reasonable way of addressing this build issue would be to get rid of WebCore::JSONObject. 125688 4 mrowe 2009-06-13 16:02:28 -0700 Perhaps Pavel can explain why WebCore::JSONObject is needed and why it refers to JSON in its name. 125695 5 timothy 2009-06-13 16:45:02 -0700 *** Bug 26340 has been marked as a duplicate of this bug. *** 125696 6 timothy 2009-06-13 16:46:17 -0700 My comment from bug 26340. Now that I look at JSONObject, it is just to similar to ScriptObject. I think it can go, and just make ScriptObject support JSON stringify and creation from a JSON string. Dimitri, Pavel, do you think that would work? 125750 7 pfeldman 2009-06-14 00:49:28 -0700 (In reply to comment #6) > My comment from bug 26340. > > Now that I look at JSONObject, it is just to similar to ScriptObject. I think > it can go, and just make ScriptObject support JSON stringify and creation from > a JSON string. Dimitri, Pavel, do you think that would work? > (commenting right but now) I agree that there is a redundancy here. However, I am not sure that Script* is now exactly what we need, so we might need to tweak them a bit. To reduce the number of the moving parts, I'd suggest that this one is fixed as suggested (via renaming Inspector's one to a more specific name) now. In the meanwhile, I would like to learn more on the new stringify API in WebKit and find a good way of Script*, new JSON.stringify and Chromium's JSON capabilities playing together nicely. 125752 8 mrowe 2009-06-14 01:34:20 -0700 (In reply to comment #7) > (In reply to comment #6) > > My comment from bug 26340. > > > > Now that I look at JSONObject, it is just to similar to ScriptObject. I think > > it can go, and just make ScriptObject support JSON stringify and creation from > > a JSON string. Dimitri, Pavel, do you think that would work? > > > (commenting right but now) > > I agree that there is a redundancy here. However, I am not sure that Script* is > now exactly what we need, so we might need to tweak them a bit. To reduce the > number of the moving parts, I'd suggest that this one is fixed as suggested > (via renaming Inspector's one to a more specific name) now. Renaming it to what? The current name is obviously terrible, as nothing at all about the type relates to JSON. Do you have any suggestions for a name? Why is renaming this type (that currently appears to serve no purpose) a better option than removing it? 125903 9 vestbo 2009-06-15 01:07:57 -0700 I'd prefer if we at least apply https://bugs.webkit.org/attachment.cgi?id=31235&action=review to rename WebCore::JSONObject while the discussion of why it needs to exists continues. At least that fixes the Qt build :/ 145199 10 vestbo 2009-09-07 10:29:48 -0700 This was fixed in r46490