RE: glib/iconv : delayed dependency

Hans Breuer wrote:
> the attached new file adds truely dynamic linking of iconv.dll
> to glib for win32. It is simply wrapping the three used
> iconv functions, to resolve them not at compile time, but
> at runtime.

Surely all use of a Windows DLL is dynamic. Does it currently use a .lib
import library? If so, then surely that is simpler than doing the same thing
manually in your own code. I generally prefer the simpler solution. My
understanding of this is described here:

> This gives the opportunity to distribute recent Gtk+ binary
> versions without just another 0.5 MB dependency.

Sure, your patch means that the actual offset is resolved at run-time, but
that doesn't necessarily mean that the binary is smaller.

Resolved-at-compile time dynamic linking is good enough for the rest of
GTK+/GNOME, so why isn't it good enough for iconv.dll?

However, I know nothing about iconv of how it is used in GTK+, so feel free
to ignore me.

Murray Cumming
murrayc usa net

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