RE: glib/iconv : delayed dependency

[Hans Breuer <hans breuer org>]

At 14:32 14.05.01 +0200, Murray Cumming wrote:
>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:
>
That's why I used the term _truely_ dynamic, and the sollution you 
suggest is the obvious thing which was done before my patch.

To point out the difference (again):
with linking a dll by .lib file the win32 dynamic linker tries to resolve
the dependency at program start. If the linked dll isn't there, the program
can't start.

My sollution - which is by no means innovative - delays the dependency to
the first call of a function requireing iconv.dll. If the program does not
do any call to the g_convert facility it simply runs without it.

>http://www.murrayc.com/learning/windows/dll.shtml#Using
>
>> 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.
>
Maybe I wasn't clear enough. The glib binary will become some
KB larger than before, but it can be used than wihout the 
0.5 MB iconv.dll.

>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?
>
AFAIK there is no official port of gnome to win32 and the dynamic 
linking concepts are slightly different between Linux and Unix. 

	Hans
-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert