Actually, despite similarities with WIN32 situation, this patch seemed to be useless in our case. I managed to go one step beyond by adding (sadly but surely ;-) Glibutilies.o + GOwnPtr.o + GrefPtr.o in WebCore.xcodeproj manually by XCODE to force LINK with these file objects... That are "generated elsewhere" by WTF.xcodeproj... Then, symbols that were assumed unresolved by WebCore are in fact defined in other locations == in WTF.
-- hmachefe PS : now => the time has come to execute binary/libraries. Lets' stay tuned. On Thu, Nov 28, 2013 at 3:46 PM, Philippe Normand <[email protected]> wrote: > I think https://bugs.webkit.org/show_bug.cgi?id=124861 is about fixing > this issue. > > Philippe > > On Wed, 2013-11-27 at 22:47 +0100, Pascal Brianceau wrote: > > Files shared by Hugo raised the same issue on my side. Did anyone make > > a step forward ? Any tip Philippe ? > > > > > > /* Pascal */ > > > > > > On Mon, Nov 25, 2013 at 9:52 AM, Hugo Machefer > > <[email protected]> wrote: > > Indeed: I didn't solve this yet; I can only say that the > > following line is "responsible for" these unresolved symbols: > > > > > > GOwnPtr<GError> error; > > > > > > -- hmachefe > > > > > > On Sun, Nov 24, 2013 at 10:04 PM, gstreamer MACOSX > > <[email protected]> wrote: > > I managed to restore < ImageGStreamerCG.cpp> however > > LINK fails : > > > > > > "__ZN3WTF13freeOwnedGPtrI7_GErrorEEvPT_", referenced > > from: > > > > > __ZN7WebCore27MediaPlayerPrivateGStreamer13handleMessageEP11_GstMessage in > MediaPlayerPrivateGStreamer.o > > __ZN7WebCore19initializeGStreamerEv in > > GStreamerUtilities.o > > > > > > -- gstreamermacosx > > > > > > PS: special thanks to hmachefe for precious > > restoration tips and to Philippe of course > > > > > > > > On Sat, Nov 23, 2013 at 9:59 AM, Philippe Normand > > <[email protected]> wrote: > > The ImageGStreamerCG implementation was > > removed in > > http://trac.webkit.org/changeset/118610 > > > > Philippe > > > > On Sat, 2013-11-23 at 00:44 +0100, Urbain EGIS > > wrote: > > > I compiled most of > > Source/WebCore/platform/graphics/gstreamer > > apart > > > from <ImageGstreamerCairo.cpp> which has a > > strong dependency on CAIRO. > > > > > > > > > It seems to be "overkill" to build WebKit by > > enabling CAIRO... Because > > > (only ;-) "one" file <ImageGstreamerCairo> > > requires a specific CAIRO > > > surface. > > > > > > > > > So What would be the best strategy in case > > of MAC ? > > > 1° activate CAIRO by WebKit and generate it > > again (+gstreamer) ... ? > > > Really ? > > > 2° get rid of CAIRO and find an alternative > > by CF/CG rather in terms > > > of surface > > > > > > > > > -- Egis > > > > > > > > > > _______________________________________________ > > > webkit-dev mailing list > > > [email protected] > > > > > > https://lists.webkit.org/mailman/listinfo/webkit-dev > > > > > > _______________________________________________ > > webkit-dev mailing list > > [email protected] > > > https://lists.webkit.org/mailman/listinfo/webkit-dev > > > > > > > > _______________________________________________ > > webkit-dev mailing list > > [email protected] > > https://lists.webkit.org/mailman/listinfo/webkit-dev > > > > > > > > > > _______________________________________________ > > webkit-dev mailing list > > [email protected] > > https://lists.webkit.org/mailman/listinfo/webkit-dev > > > > > > > > _______________________________________________ > > webkit-dev mailing list > > [email protected] > > https://lists.webkit.org/mailman/listinfo/webkit-dev > > > _______________________________________________ > webkit-dev mailing list > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-dev >
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
