[Mingw-users] Re: Solving the "relink exe's" libtool problem

[Alexandre Duret-L. <du...@lr...>]

>>> "Chuck" == Charles Wilson <cw...@ec...> writes:

 Chuck> There has been a long-standing problem with libtool on windows-ish
 Chuck> platforms (cygwin, mingw, others?), in which libtool relinks exe's
 Chuck> over and over and over, when the exe depends on a shared lib that is
 Chuck> also built as part of the same package.

 Chuck> This behavior is due to the necessity that we must use a wrapper
 Chuck> script to set the PATH properly, so that the newly compiled exe can
 Chuck> "find" its shared lib, when run "in place" -- e.g. as part of a
 Chuck> test-suite.  Thus, we have

 Chuck> <build-dir>/foo             (wrapper script)
 Chuck> <build-dir>/.libs/foo.exe   (real exe)

 Chuck> However, the Makefile target is "foo$(EXEEXT)" -- which
 Chuck> isn't satisfied by the "foo" wrapper script, so 'make'
 Chuck> keeps trying to create it. 

Maybe I'm wrong, but my understanding is that wrapper scripts
are generated only when linking programs with uninstalled shared
libraries.

For instance wrapper scripts aren't created when the user uses
--disable-shared, or simply if some program in the package
doesn't link with shared libraries.  In these cases reseting
EXEEXT globally doesn't look like a solution (I guess it would
just create the converse issue: the `foo:' target not satisfied
by `foo.exe').

In the current situation I don't think there is any way to find
out whether a Makefile target needs `.exe' appended.

 Chuck> However, the wrapper script can NOT be named "foo.exe",
 Chuck> for a number of good reasons.

I assume these reasons are related to the word `script'?
Have binaries been considered?

[...]
-- 
Alexandre Duret-Lutz