[webkit-dev] WebCore/platform standalone library

[Konstantin Tokarev]

13.01.2017, 19:26, "Michael Catanzaro" <mcatanzaro at igalia.com>:
> On Fri, 2017-01-13 at 11:39 -0200, Gustavo Sverzut Barbieri wrote:
>>  On Thu, Jan 12, 2017 at 7:11 PM, Alex Christensen
>>  <achristensen at apple.com> wrote:
>>  > If PAL were a shared library in a CMake build, then it wouldn’t
>>  > build successfully if there were layering violations.  I think we
>>  > should do something like that to enforce good design, even if the
>>  > Mac Xcode projects treat it as a static library or even just a part
>>  > of WebCore.
>
> Why does it matter if it's static or shared? Surely if PAL is build
> before WebCore, and it's missing symbols at link time (because those
> symbols actually exist in WebCore) and not linked to WebCore, then PAL
> will fail to link regardless of whether it is a shared library or
> static library? Am I just downright wrong to assume this, or does it
> work differently on Mac...?

Static library is just an (indexed) archive of object files, symbol dependencies are not resolved when it is created. Instead this happens when static library is linked into shared library or executable.

If PAL is static and uses symbol from WebCore, link failure may happen only[*] if that symbol is not used anywhere in WebCore itself (provided that PAL stays after WebCore in linker command line and options like --start-group/--end-group are not used).

[*] Assuming linker behavior similar to ELF linkers

>
> (This is the biggest problem I see with the current plan. Regardless of
> where the directory goes and what the namespacing looks like, I really
> want to use the linker and not a python script to enforce layering.)
>
>>  Actually for development it would make lives much easier to keep it
>>  as shared library, reducing compile time and help to segment the
>>  symbols in a different space (linkers, gdb)
>>
>>  what if it becomes shared by default on Debug builds, static by
>>  default in Release?
>
> For GTK+, I'd really like it to be always a static lib as that's what
> we need to ship and I wouldn't want to support multiple configurations.
> Debug fission has solved our troubles with link time and gdb slowness.
> But here it's possible for different ports to do different things. E.g.
> some ports support building WebCore as a shared library, which is not
> supported by GTK+.
>
> Michael
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin