Solving the "relink exe's" libtool problem [take 2]

[Charles Wilson]

Alexandre Duret-Lutz wrote:
>  Chuck> Said "stub" executable would have to do ALL of the
>  Chuck> things the script does, and then pass that environment
>  Chuck> to its exec'ed target in .libs/ --
> 
> Maybe it could just exec() something like `/bin/sh .libs/foo.sh',
> where `.libs/foo.sh' is the script wrapper.

Good idea.  Try this version...

It no longer requires any coordination with automake; it's all 
implemented in ltmain.sh and doesn't mess with EXEEXT or LT_EXEEXT.

Now, this isn't perfect -- it solves the problem, has no regressions on 
cygwin, and is probably okay for inclusion in libtool CVS.  But there 
are stylistic warts that could be sanded off, if someone else were to 
take the effort (hint, hint)

The following behavior is only "active" when $host is cygwin or mingw:

I left the shell wrapper where it was, in the build directory.  When 
creating the shell wrapper, libtool will also create lt-${prog}.c and 
compile it using
    $run $LTCC -s -o ${prog}.exe lt-${prog}.c

So, you end up with:

<builddir>/foo           (shell wrapper)
<builddir>/foo.exe       (binary wrapper)
<builddir>/lt-foo.c
<builddir>/.libs/foo.exe (the real executable)

Since builddir contains foo.exe, make is happy.  ./foo.exe execs 
"/bin/sh foo", which sets up the environment and calls .libs/foo.exe.

Eventually, the functionality of the shell wrapper could be moved into 
the source code for the binary wrapper, and we could drop the shell 
wrapper completely for cygwin/mingw $host.

So the fact that the shell wrapper is still there is a wart (but 
removing the shell wrapper creates its own difficulties -- see next point).

There are two places in ltmain.sh where the shell wrapper is directly 
sourced.  This doesn't work very well, because when both "foo" and 
"foo.exe" exist, ". ./foo" ends up sourcing "foo.exe" -- which is bad.

[Note, if the shell wrapper is eliminated, then somehow libtool needs to 
be able to get the info embedded into the binary wrapper.  Maybe the 
binary wrapper needs a "--shell" option, that emits what is effectively 
the current shell script?  But then, that's just another wart (`binwrap 
--shell > shellwrap`; . shellwrap ; rm shellwrap), unless there is a way 
to "source" rather than execute the contents of a variable.]

But, if both the binary wrapper and the shell wrapper exist, there are a 
few ways to solve the conflict that occurs when libtool tries to source 
the shell wrapper (and sources the binary wrapper instead):
   (1) prior to directly sourcing the shell wrapper into libtool's 
memory space, make a temporary copy with a name that doesn't conflict 
with "foo.exe" in the same way that "foo" does.  E.g.
       cp foo lt-foo.sh
       . ./lt-foo.sh
       rm -f lt-foo.sh
Yes, it's a race condition, but it should be temporary pending further 
work...

   (2) on the cygwin/mingw platforms, change the name of the shell 
wrapper itself.  So don't create "foo" at all; instead, create lt-foo.sh 
(or .libs/foo.sh).  But this requires catching ALL of the places were 
$output or $outputname are set, and fixing them with case $host ; 
*cgywin* | *mingw* ) ... ;; esac blocks.  Blech.

I did #1, as it appeared to require fewer modifications.  ($output and 
$outputname are set in SO many different places...)  Plus, I anticipate 
that, at least on cygwin/mingw, we might eventually completely do away 
with the shell wrapper by incorporating its functionality within the 
binary wrapper(given the caveats re: --shell above)...an added incentive 
to avoid disrupting the rest of ltmain.sh beyond the absolute minimum.

Also, there may be some complaints about using $LTCC to build the binary 
wrapper, especially in the context of a cross compiler.  Here's a block 
of comments from the patch:

# we should really use a build-platform specific compiler
# here, but OTOH, the wrappers (shell script and this C one)
# are only useful if you want to execute the "real" binary.
# Since the "real" binary is built for $host, then this
# wrapper might as well be built for $host, too.
$run $LTCC -s -o $cwrapper $cwrappersource

--------------------------------------

cgywin: if you've already installed my test versions of automake and 
libtool (automake-devel-1.7.2-2 and libtool-devel-20030103-2), you must 
revert to the "REAL" cygwin automake-devel-1.7.2-1.  Then, update to 
libtool-devel-20030103-3 which is now available by pointing setup.exe at
   http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/

mingw: test reports?

automake: please ignore the previously posted patch

libtool: Hopefully this gives a starting point for further refinement. 
But IMO it is okay (e.g. functional) for inclusion into CVS as-is, 
provided that it causes no problems on non-windows, and fixes the 
relink-exe problem on mingw.  It DOES fix the relink-exe problem on cygwin.

---------------------------------------

--Chuck
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: libtool-relinkexe2.changelog
URL: <http://cygwin.com/pipermail/cygwin/attachments/20030113/24b06ec9/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: libtool-relinkexe2.patch
URL: <http://cygwin.com/pipermail/cygwin/attachments/20030113/24b06ec9/attachment-0001.ksh>