[poky] [PATCH] meta: Add support for GTK+-3.0 static libraries

[Burton, Ross]

On 6 July 2017 at 00:16, David Freitag <DFreitag at environics.com> wrote:

> > GTK+ for many years has explicitly disabled static libraries, which is
> why you need to override that here.  That is my first hint that this may
> not be right.
>
> Interesting. Given this, would a patch of this nature even be merged
> upstream? Would a disabled-by-default PACKAGECONFIG be welcome?


I'd be opposed to enabling a static build of GTK+ out of the box because of
how many limitations it has (see below). GTK+ doesn't want to support
static linking because statically linking to GTK+ isn't really possible in
the real world.


> > *If* you want to support a static build of GTK+ then there are ways you
> can make it sort of work, but this is not it.  Look up
> --with-included-immodules, --disable-modules, etc in the GTK+
> documentation, and pass those.  You should end up with a static gtk+ which
> contains all the input method modules builtin, but as far as I know
> printing will still be broken.
>
> As the target system is an embedded device without the ability to print in
> the first place, losing support for print backends is a non-issue.
> Supposing a patch of this nature is welcome upstream, there would be a
> bitbake warning about this lack of support.


It's not just printing, of course.

GIO modules are all loaded at runtime.  gdk-pixbuf loaders are loaded at
runtime by default. Input method modules are loaded at runtime by default.
You may be willing to take the hit on all of this in your build but I don't
think it should be available as an option out of the box.

Seriously, have you considered not statically linking? This isn't 1987
anymore, even in embedded...

Ross
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/poky/attachments/20170706/3fc8a1be/attachment-0001.html>