Perhaps contact your lawyer and ask him to explain you that license.
(and that explains why you won't have many examples of statically
linking GTK3; it is useless to do so, and in some cases might be a
Take into account the freedom of the user of your binary program. He
should be allowed to upgrade, following the LGPL license,
his version of GTK3 inside your product. The easy way to ensure freedom
is to dynamically link your product with the libgtk*.so
El 30/11/17 a las 13:11, [hidden email] escribió:
> Beware that releasing such a static library in binary form (without
> its source code) is probably a violation of the LGPL license.
> Read carefully the LGPL2.1 license of GTK.
> https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html >
> Perhaps contact your lawyer and ask him to explain you that license.
To safely distribute a program with an statically compiled GTK3, you
must do at least:
- Since GTK3 is LGPL, you must include the source code of the GTK3
version you used
- Also include all the source code of every other LGPL library you used
- Finally you must include all the object files (.o) generated by your
code and other non-free libraries
The first and second points are obvious: you are distributing GTK3 in
your program, which is free software, so you must also include the
source code of the LGPL part.
The third one is trickier. Since you must allow the user to link your
software with newer or modified versions of the LGPL libraries, in a
statically compiled system there is only one possibility: to include the
object code files of everything non-LGPL. This allows the user to
recompile new/modified versions of the free libraries, and then link
your code with them.
While we don't actively disable static builds, we're also not really
using them, or testing them. This typically means that doing static
builds of GTK (and its dependencies) is discouraged, or at least that
you're basically on your own.
To be fair, there's literally no reason whatsoever to do a static
build; this is not 1983. You're going to waste more resources (loading
time, storage space) doing a static build of everything, these days.
My strong suggestion is to simply ship your application in a bundled
archive that replicates the file system layout that GTK expects,
alongside a launcher that sets up the execution environment by
modifying PATH, linker paths, and environment variables such as
XDG_DATA_DIRS and friends; then, distribute your application that way.
If you're using Linux, I strongly recommend you look at Flatpak:
Le 30 novembre 2017, à 12:44, Emmanuele Bassi a écrit :
> To be fair, there's literally no reason whatsoever to do a static
> build; this is not 1983. You're going to waste more resources (loading
> time, storage space) doing a static build of everything, these days.
I think there are some good reasons. For example, see
http://www.musl-libc.org/intro.html . However I'm no expert in this field,
so I'm not going to argue myself; I'm just saying that there are experts
who do static linking, so there must be good reasons to do so.
> My strong suggestion is to simply ship your application in a bundled
> archive that replicates the file system layout that GTK expects,
> alongside a launcher
Is this supposed to save loading time and storage space?