[Webkit-unassigned] [Bug 183595] Cmake for static build of libjavascriptcoregtk and libwebkit2gtk fails: install TARGETS given no ARCHIVE DESTINATION for static library target "WebKit".

[bugzilla-daemon at webkit.org]

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

--- Comment #13 from Stefan Fröberg <sfroberg13 at yahoo.com> ---
(In reply to Adrian Perez from comment #7)
> Hi Stefan! Indeed it is tricky to get static builds to work (as you
> have already discovered!), so I wanted to chime in to give you a couple
> of possible alternatives that you may want to consider:
> 
>  * Build WebKitGTK+ as dynamic libraries, using a custom installation
>    prefix, e.g. with “-DCMAKE_INSTALL_PREFIX=/usr/libexec/yelp-webkit”,
>    disabling the WebKitGTK+ features that Yelp does not need to work, 
>    and then linking Yelp to the libraries in the custom prefix.
> 
>  * Use something like Flatpak which is precisely intended for bundling
>    applications, where application bundles can have their dependencies
>    included with them. You could have a custom Flatpak build of Yelp
>    for your distribution which includes a custom build of WebKitGTK+
>    inside the application bundle.
> 
What would be the pro's and con's of those approach?
Does the user need to install extra stuff for example? Does it need specific support from distro?

What Im trying to do is build as self-standing app as possible without needing to worry things crazy things like: glibc versioning, having static binary that is not really static (glibc dlopen thing) and so on....

static build musl library would have allowed me to do that but unfortunatley it's not playing nicely with webkit...



> Any of the above will get you out of the “build a static WebKitGTK+”
> minefield. That being said, we are not against using static builds of
> WebKitGTK+ but as Michael already mentioned, it is not a particularly
> attractive option: static builds prevent the multiple processes that
> are needed by WebKitGTK+ from sharing the code segments of the shared
> libraries (which saves both disk space and memory).


Okay, is there anyway that the pulled depencies, at least for some of those three *Process files could be lessened? That would greatly help with the size...

Now, for example, this is best I can do:

-rwxr-xr-x 1 wizard wizard 95M maali 14 17:09 WebKitWebProcess


95 MB, for one of the three *Process files. that added with the other and the app itself the total size is around 285 - 380 MB ... jeez... (as a side note, Qt port of webkit(1?) is only 78 MB as static)


I give my musl-static build another run, try to produce patch and then test that with glibc and see how that works.

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