[ITP-2] glib-2.4.2-1

[Charles Wilson]

Gerrit P. Haase wrote:

> No and yes, and IIRC, the script doesn't work because the libtool-devel
> creates a dummy executable, so if there are glib-genmarshal and
> glib-genmarshal.exe in the same directory, glib-genmarshal.exe will be
> executed at first and since it is a dummy it fails.

Actually, libtool works thus, in most cases:
   the "real" but not-yet-installed executable is in <build>/.libs/
      <build>/.libs/lt-foo.exe (?)

   there is a wrapper script sets env vars (like LD_LIBRARY_PATH on 
unix, or PATH on windows) so that the "real" executable will use the 
correct shared libs.  It is in <build>/.
      <build>/foo

   to avoid the "libtool always relinks everything" problem on 
windows/mingw/cygwin, libtool creates a dummy executable in the <build> 
dir which simply launches the wrapper script, when in turn launches the 
real exe.  (It's obviously theoretically possible to combine the wrapper 
exe and the wrapper script into a single wrapper(.exe?) -- but for 
technical reasons it's difficult to do so and not break other platforms)
      <build>/foo.exe

> I patched it to call the real executable.

But then, your PATH is not set correctly, so the "real" executable will 
load the installed versions of its DLLs -- which may not be what you want.

Now, this whole scheme obviously causes problems when you want to parse 
the binary for symbols, in order to build a dynamic symbol 
lookup/dispatch table -- like genmarshal.  It's a problem even for 
libtool's own ltdl library on cygwin.  Gary Vaughan sez that the "new" 
version of m4 will make this a lot easier to handle by simpifying the 
stuff in libtool.m4, so we'll see.  OTOH, Gary's creating something of a 
chicken/egg problem, as the new m4 itself needs working ltdl support...

--
Chuck