Re: static linking on mingw/msys



Martin Schmeisser writes:
Hehe, darn, thats why.  So is there a way to find out what dlls it linked
againts?

Of course there is, "link -dump -imports" or "objdump -p". But recall
that GTK+ also loads DLLs dynamically (gdk-pixbuf loaders mainly, but
also theme engines for instance). It also reads configuration files
which it expects to be in the installation tree at certain fixed
locations relative to the installation folder's root.

I dont want my dad to intall the gtk runtime on about 20 boxes he
is going to use this app on,

That's like saying "I want my app to use GTK+ but I don't want to use
GTK+".

What's so hard in making one zip archive containing the tree that will
have to be "installed" (unzipped) on the end-user machines?

You will need the gtk runtime. (And its run-time dependencies,
i.e. libpng, zlib. pango, cairo, glib, gettext, libiconv. Did I recall
all?) But you don't necessarily need *all* of it. If your app is in
English also (and your users), you can leave out the entire lib\locale
subtree, for instance. You can leave out those gdk-pixbuf loaders that
you don't need. (Most probably, you will only need the png loader, for
instance.) You can leave out the pangoft2 DLL.

(Note that the recent Pango Win32 builds have the Pango shaper modules
built-in into the DLLs, i.e. in Pango's case there are now less
run-time files needed, the modules aren't loaded at run-time any
longer.)

so maybe i can just put the dlls in the same folder as the binary?

It's better to see it the other way; put your app exe is the same
folder as the DLLs. What you should *not* do is move the GTK+ DLLs in
relation to the other files from the GTK+ runtime that they need.

--tml




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]