Solving the "relink exe's" libtool problem

[Charles Wilson]

[cross posted.  Please keep (at least) cygwin@cygwin.com in all replies, 
especially as the @gnu.org mailserver has not been archiving all messages]

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

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

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

However, the Makefile target is "foo$(EXEEXT)" -- which isn't satisfied 
by the "foo" wrapper script, so 'make' keeps trying to create it. 
However, the wrapper script can NOT be named "foo.exe", for a number of 
good reasons.

For more information on this problem, see

Cygwin List O' Issues (take 2): #3 relinking exe's
http://mail.gnu.org/pipermail/libtool/2002-November/007153.html
There is an attachment that demonstrates the problem; I've also attached 
it directly to this email.

EXEEXT and -link
http://mail.gnu.org/pipermail/libtool/2002-October/007131.html

Based on Earnie's suggestion in the second message, I have implemented a 
solution, but it is TIGHTLY linked between automake and libtool.  This 
linkage is necessary because both libtool and automake 'use' the value 
of EXEEXT in a number of places; by saving its value and resetting it to 
null in libtool, we must re-supply the original value *in some places, 
but not others* so that automake works properly -- which means automake 
needs to "know" about the new variable that holds the original value of 
EXEEXT.

On non-windows platforms, EXEEXT is null.  (pre-existing, unchanged)
On all platforms, LT_EXEEXT is null without the libtool changes.

Thus, on non-windows platforms, the automake changes have no effect, 
even if they are accepted (and used) without the corresponding libtool 
changes.

Similarly, on non-windows platforms, the libtool changes have no effect, 
even if they are accepted (and used) without the corresponding automake 
changes.

However, on windows-ish platforms, you must have BOTH changes or NEITHER 
-- or else things break.  (Actually, it's not QUITE that bad.  Even on 
windows, IF you have only the automake changes -- but don't use libtool 
at all, then things are fine.  No probs.  But you can't use an updated 
automake + non-updated libtool, and you can't use non-updated automake + 
updated libtool.)

So, for non-windows, each patch can be accepted and applied 
independently.  For windows, they need to be synchronized -- but perhaps 
the autotool maintainers for cygwin (me) and mingw/MSYS (Earnie) can 
handle that *synchronization* "outside the tree" -- as long as it is 
clear that *eventually* both patches will make it in to their respective 
codebase.

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

For testing purposes, I've provided automake-devel-1.7.2-2 and 
libtool-devel-20030103-2 packages for cygwin.  Just point setup.exe at

http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/

and select the appropriate packages.

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

I've attached the changelogs and patches for both automake (against 
1.7.2) and libtool (against current CVS).  I've also attached a simple 
testcase.  Just unpack, run ./bootstrap, ./configure, make.

Then 'make' again.  Without these changes, program.exe will be relinked. 
  With these changes it will not be.  'make install' and 'make 
uninstall' work as expected -- without relinking, with these changes.

I've run the testsuites of both automake and libtool with these changes, 
and have had no regressions -- but they ran a lot faster... <g>

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

Cygwin people: please test
Mingw/MSYS people: please apply to your own packages, and test
Libtool people: please apply?
   I'd really like to make sure this or something like it
   gets into 1.5...
Automake people: please apply?

I realize that, even if all of the cygwin and mingw people say "this is 
great", we will still require some coordination between the libtool and 
automake folks to insure both sets are eventually accepted and the 
timing of that acceptance.

--Chuck
cygwin libtool maintainer
cygwin automake co-maintainer
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: automake.changelog
URL: <http://cygwin.com/pipermail/cygwin/attachments/20030113/5972ce7b/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: libtool.changelog
URL: <http://cygwin.com/pipermail/cygwin/attachments/20030113/5972ce7b/attachment-0001.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: automake.patch
URL: <http://cygwin.com/pipermail/cygwin/attachments/20030113/5972ce7b/attachment-0002.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: libtool.patch
URL: <http://cygwin.com/pipermail/cygwin/attachments/20030113/5972ce7b/attachment-0003.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: relinkprog-demo.tar.bz2
Type: application/octet-stream
Size: 2211 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20030113/5972ce7b/attachment.obj>
-------------- next part --------------
--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/