The libtool 1.4.x processing (and patched 1.3.5) uses a little
"impgen" tool to turn a "*.dll" into an import "*.lib" as it is
needed for win32 targets. However, this little tool is not shipped
by binutils, it is not even a command option of dlltool or dllwrap.
It happens to be a C source snippet implanted into the libtool
sources - it gets written to ".libs", compiled into a binary
on-the-fly, and executed right away on the "dll" file to create
the import-lib (dll.a files in gcc-speak).
This mode works fine for a native build within mingw or cygwin,
but it does not work in cross-compile mode since CC is a
crosscompiler - it will create an .exe file on a non-win32
system, and as a result an impgen.exe is created on-the-fly
that can not be executed on-the-fly. Luckily, the actual
libtool snippet uses HOST_CC to compile the sources which
has a fallback to CC when the HOST_CC variable was not set.
this ac-macro is trying to detect a valid HOST_CC which is not
a cross-compiler. This is done by looking into the $PATH for
a "cc" and the result is patched into libtool a HOST_CC, iow
it adds another configured variable at the top of the libtool
script.
In discussions on the libtool mailinglist it occurred that
later gcc/binutils generations are able to link with dlls
directly, i.e. there is no import-lib needed anymore. The
import-table is created within the linker itself (in-memory)
and bound to the .exe/.dll currently in the making. The
whole stuff of impgen exe and compiling it on-the-fly, well,
it is superflouos then.
Since mingw crosscompilers tend to be quite a fresh development
it was agreed to remove the impgen stuff completly from
libtool sources. Still however, this macro does not hurt
since it does not patch impgen cmds but it just adds HOST_CC
which might be useful in other cross-compiling cases as well.
Therefore, you can leave it in for maximum compatibility and
portability.
@= guidod@gmx.de
@$Id: patch_libtool_to_add_host_cc.m4,v 1.3 2003/03/23 13:20:27 guidod Exp $