Re: Solving the "relink exe's" libtool problem

[Charles Wilson <cwilson at ece dot gatech dot edu>]

Alexandre Duret-Lutz wrote:

>  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.
Yes.

> 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').
eh, sort of.  If we were still in the days of yore, then you would be 
correct.  However, more modern cygwin and mingw environments (e.g. MSYS) 
provide a patched 'make' that works around the issue.  In fact, foo.exe 
DOES satisfy a 'foo:' rule, but NOT vice versa.  That's why it is okay 
to get foo.exe when building 'foo:' statically, but it *wasn't* okay to 
get foo when building 'foo.exe:' dynamically.

> In the current situation I don't think there is any way to find
> out whether a Makefile target needs `.exe' appended.
Right.  But given the hacked 'make's that are used on cygwin and mingw, 
this solution works "as expected" for both staticly and dynamicly linked 
executables -- on the platforms that these variables (EXEEXT, LT_EXEEXT) 
actually affect.

'Course, there's the whole cross-compiler issue (running on linux, 
building stuff intended for cygwin).

>  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?
Hmmm...now there's a thought.  Perhaps, perhaps...

Said "stub" executable would have to do ALL of the things the script 
does, and then pass that environment to its exec'ed target in .libs/ -- 
does native windows provide an exec() command?  Environment inheritance? 
 You'd probably need different source code for the stub, depending on 
the platform... if buildhost == posixy, then exec() is our friend; 
otherwise, nasty native Windows code...

Unfortunately, I can't work on that right now; my available time just 
went to zero. :-(

--Chuck