Re: Portability and distribution with Gtk+ 1.3

[Havoc Pennington <hp redhat com>]

Arnaud Charlet <charlet ACT-Europe FR> writes: 
> With Gtk+ 1.3.3, this is certainly no longer true, and Gtk+ is now a complete
> system on its own, very much like Gnome is.

With one substantial difference, which is reluctance to depend so much
on the runtime environment (i.e. we are not expecting CORBA to work
properly, there are not daemons such as oafd and gconfd, etc.)

> Is this intended ? Are they plans to reduce the dependencies ? Simplify
> installation and portability ?

The basic fact is that most users want features such as image loading
("how do I load a JPEG?" is a huge FAQ on the lists) while relatively
few users care much about dependency lists. So to the extent that
there's a tradeoff, no it isn't going to be changed.

However, to the extent that both groups of users can be made happy,
yes we would love patches and concrete suggestions. e.g. Alex did the
work to support --with-included-modules in gdk-pixbuf.

Note that libpng is only used at compile time to run
make-inline-pixbuf for example, so you could change the makefiles to
run --make-inline-pixbuf at 'make dist' time perhaps, and distribute
the generated files with the tarball. So then end users could build a
zlib-free png-free gtk.

I know highly portable projects such as Mozilla and AbiWord do use
libpng though, so you may wish to investigate how they've addressed
any zlib issues.

> I mean dependencies that do not appear in the linked executable, but appear
> only at run time, by the mean of dlopen().

When it's missing, adding the equivalent of the
--with-included-modules flag for these would be welcome.

> - there is now systematically a dependency on the thread
>   library (libgthread + libpthread) which is not desirable for non threaded
>   applications

I believe you can build without pthread, if you pass the right stuff
to glib configure.

> - the number of shared libraries not referenced at link time is big
> - libraries loaded with dlopen apparently need to be put at known
>   and fixed locations.
> - have an application linked statically with Gtk+ sounds like a real
>   challenge.

Specific bug reports (bugzilla.gnome.org) and fixes in this area would
be good. We do want to support statically linked apps, but aren't
necessarily aware of all the issues, so if you're working on this and
can help point out all the specific stuff that comes up, it would be
invaluable.

To make linking statically "just work" I suppose we'd need to build
the .a libs with everything included, and the .so libs with dlopened
modules, I don't know if that's a good idea though. Seems like it
might be confusing. You might experiment with getting automake/libtool
to do this and see if it works well.

Havoc