[Webkit-unassigned] [Bug 36088] [gtk] DumpRenderTree build failure: multiple definitions of symbol _kJSClassDefinitionEmpty

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=36088





--- Comment #6 from Tim Lyons <guy.linton at gmail.com>  2010-03-30 11:13:06 PST ---
(In reply to comment #5)
> (In reply to comment #3)
> 
> 
> Is this when also changing in the WebKitTools/GNUmakefile.am template, or just
> in the derived GNUmakefile.in derived file? The warnings suggest you are
> changing some template still, rather than just the higher level files in the
> built set. Or else if you are going to patch the low-level
> WebKitTools/GNUmakefile.am, propagate that change by redoing the autotools
> chain (autoreconf, or some similar command, not sure what is the recommended
> way for the webkit build system).
> 
> Can you get MacPorts to give a more verbose build, so you can verify that the
> order is changed in the actual linker call? 'make V=1' or passing
> --disable-silent-rules to ./configure or something like that? Is the -d flag
> relevant to debugging the build or just debugging the macports process?



As far as I can understand, MacPorts does not run automake by default, hence I
have not run it at all.

I have now edited Makefile.in and run the build part again with MacPorts debug
output, and I have now managed to change the order of the link (see the debug
output configurelog2.txt attached: the last link includes:

-L/opt/local/lib ./.libs/libJavaScriptCore.a ./.libs/libwebkit-1.0.dylib
/opt/local/lib/libenchant.dylib)


(I changed GNUmakefile.in)

However, it still gives the error about multiple definitions of symbol
_kJSClassDefinitionEmpty.

I don't understand why changing the order would avoid the duplicate: if the
symbol is defined twice surely it is defined twice whatever the order?

(Since I am not running automake, I think the warning is indeed a separate
problem, and probably just a warning when the build is running, and reporting
on the files it is using).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.