Re: Portability and distribution with Gtk+ 1.3

[Arnaud Charlet <charlet ACT-Europe FR>]

Thanks for the answers.

> 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.)

Yes, definitely true.

> 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.

OK, I guess it is a matter of always requiring the dependencies, or having
a way to separate them. As far as I understand you welcome suggestions
to enable separation and such.

> 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.

Interesting. Will see what can be done in this area.

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

Agreed.

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

The trouble is that I do not want to reconfigure/rebuild/reinstall glib
each time I build a new application that has or doesn't have threads.

Unless I am missing something, with Gtk+ 1.2, as long as you do not
use libgthread explicitely, you do not depend on libgthread not libpthread,
even when glib has been configured with --enable-threads
(the default I believe).

This is this change of behavior that I find annoying, but if it is an unwanted
change, it might be possible to fix/revert this change.

> 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.

Understood. Of course, having more documents explaining what is the current
state, and what is expected would help, as there some work in the area
(done or in progress) ?

> 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.

Well, having everything included in the .a will also mean that generated
executables will be huge, will is not a negligible point for statically
linked executables. I guess the --with-included* options address part of this
concern (even if again, this is a configure time option, which is not
very flexible since it is not practical to reconfigure and rebuild the
"Gtk world" again and differently for each application and on each target.

Arno