Re: Static linking in GTK Windows

[Tor Lillqvist <tml iki fi>]

> link in the .a files for each dll rather than the dll itself. This will
> work but result in a huge, 14 MB executable!

What .a files? If the user has my binary Win32 distribution of GTK+
(as opposed to built it himself), there are only DLLs (and import
libraries) included. AFAIK, the other binary Win32 distributions (like
the "gtk-dev" stuff) are repackagings of my builds, so there aren't
any generally available static libraries.

This is intentional. GTK+ and Pango on Win32 *require* being built as
DLLs in order to be able find their configuration files and message
catalogs at run-time. On Unix, the installation prefix is fixed at
configure time, and hard-coded into the (static or shared)
libraries. This is not seen as a problem on Unix, if there isn't room
to actually install GTK+ where it wants to be instaled, you can always
play games with symbolic links. 

On Windows, requiring end-users to install GTK+ into some fixed
location (like C:\GTK+, or C:\Program Files\Common Files\GTK+) would
be very stupid. For instance, I don't even have any C: drive on my
home Win2k machine. Also, the name of the Program Files folder is
localised in various language Windows versions.

Sure, it would be possible to require either some Registry entry or
environment variable to point to the installation directory if GTK+
and Pango were static libraries. But I am not going to add code for
this unless somebody submits a ready-to-use clean patch, and even then
I will personally continue to build and distribute only DLLs. DLLs are
so natural in the Windows environment.

I guess that the reason the original poster wants a static library is
so that he needs to distribute less files with his application? This
is misguided thinking. GTK+ is a big library, and if it's larger than
an application using it, so what... He should also take into
consideration how the LGPL affects his software if he links statically
to LGPL code. (Or is there any difference?  Can't remember right now.)
Also, one very imporant selling point of GTK+, GLib etc is i18n. It
would be a bad idea not to distribute the message catalogs to
end-users.

--tml