[Webkit-unassigned] [Bug 144557] [GTK] OSX linker doesn't understand --whole-archive

[bugzilla-daemon at webkit.org]

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

--- Comment #6 from Martin Robinson <mrobinson at webkit.org> ---
Comment on attachment 252688
  --> https://bugs.webkit.org/attachment.cgi?id=252688
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=252688&action=review

>>> Source/WebKit2/PlatformGTK.cmake:875
>>> +    COMMAND CC=${CMAKE_C_COMPILER} CFLAGS=-Wno-deprecated-declarations LDFLAGS=-lGObjectDOMBindings
>> 
>> This looks unrelated.
> 
> These are related though; it's what I was referring to with "link with extra libraries instead" in the patch's changelog. Without --whole-archive, these libraries don't get picked up for linking, so I have to add them manually.
> 
> I wonder if it might make sense to get rid of the ADD_WHOLE_ARCHIVE_TO_LIBRARIES macro entirely, since all the necessary libraries are now added manually. Alternatively, I could bracket these manual additions inside CMAKE_SYSTEM_NAME checks.

If you can get WebKitGTK+ to compile properly on Linux and on the build bots without ADD_WHOLE_ARCHIVE_TO_LIBRARIES, feel free to remove it.

>> Source/WebKit2/PlatformGTK.cmake:890
>> +        --library=c++
> 
> Ditto.

Hrm. Is c++ a system library or a special value understood by g-ir-scanner? If it's the latter, is it documented somewhere?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151012/e312816f/attachment.html>