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

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

[Michael Bester]

Charles Wilson wrote:

> [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
>
>------------------------------------------------------------------------
>
>2003-01-05  Charles Wilson  <cwilson@ece.gatech.edu>
>
>	* lib/am/program.am: when %?LIBTOOL%, use $(LT_EXEEXT)
>	not %EXEEXT%
>	* lib/am/progs.am (install-%DIR%PROGRAMS): when %?LIBTOOL%,
>	use $(LT_EXEEXT) not $(EXEEXT).  Insure that we test for 
>	both foo and foo$[LT_]EXEEXT.  Insure that we install 
>	foo$([LT_]EXEEXT) and not foo.
>	(uninstall-%DIR%PROGRAMS): when %?LIBTOOL%, use 
>	$(LT_EXEEXT) not $(EXEEXT)
>	(clean-%DIR%PROGRAMS): when %?LIBTOOL%, use $(LT_EXEEXT),
>	not $(EXEEXT). Insure that we remove both foo$(LT_EXEEXT)
>	and foo.
>
>  
>
>------------------------------------------------------------------------
>
>2002-01-05  Charles Wilson  <cwilson@ece.gatech.edu>
>
>	* libtool.m4 (_LT_EXEEXT): new function
>	(AC_LIBTOOL_SETUP): call it
>	* tests/Makefile.am: pass $(LT_EXEEXT) on to
>	TEST_ENVIRONMENT
>	* tests/build-relink.test: use $(LT_EXEEXT) 
>	instead of $(EXEEXT)
>	* tests/dryrun.test: ditto
>	* tests/noinst-link.test: ditto
>  
>
>------------------------------------------------------------------------
>
>diff -u automake-1.7.2-orig/lib/am/program.am automake-1.7.2/lib/am/program.am
>--- automake-1.7.2-orig/lib/am/program.am	2002-12-06 04:53:18.000000000 -0500
>+++ automake-1.7.2/lib/am/program.am	2003-01-05 18:09:01.000000000 -0500
>@@ -15,6 +15,12 @@
> ## along with this program; if not, write to the Free Software
> ## Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
> ## 02111-1307, USA.
>+if %?LIBTOOL%
>+%PROGRAM%%EXEEXT%: $(%XPROGRAM%_OBJECTS) $(%XPROGRAM%_DEPENDENCIES) %DIRSTAMP%
>+## take care of wrapper script, static executable, and dynamic executable
>+	@rm -f %PROGRAM% %PROGRAM%$(LT_EXEEXT) .libs/%PROGRAM%$(LT_EXEEXT) _libs/%PROGRAM%$(LT_EXEEXT)
>+	$(%XLINK%) $(%XPROGRAM%_LDFLAGS) $(%XPROGRAM%_OBJECTS) $(%XPROGRAM%_LDADD) $(LIBS)
>+else !%?LIBTOOL%
> %PROGRAM%%EXEEXT%: $(%XPROGRAM%_OBJECTS) $(%XPROGRAM%_DEPENDENCIES) %DIRSTAMP%
> ## Remove program before linking.  Otherwise the link will fail if the
> ## program is running somewhere.  FIXME: this could be a loss if
>@@ -23,3 +29,4 @@
> ## systems.
> 	@rm -f %PROGRAM%%EXEEXT%
> 	$(%XLINK%) $(%XPROGRAM%_LDFLAGS) $(%XPROGRAM%_OBJECTS) $(%XPROGRAM%_LDADD) $(LIBS)
>+endif !%?LIBTOOL%
>diff -u automake-1.7.2-orig/lib/am/progs.am automake-1.7.2/lib/am/progs.am
>--- automake-1.7.2-orig/lib/am/progs.am	2002-12-06 04:53:19.000000000 -0500
>+++ automake-1.7.2/lib/am/progs.am	2003-01-05 18:43:30.000000000 -0500
>@@ -36,8 +36,11 @@
> 	@list='$(%DIR%_PROGRAMS)'; for p in $$list; do \
> ## On Cygwin with libtool test won't see `foo.exe' but instead `foo'.
> ## So we check for both.
>-	  p1=`echo $$p|sed 's/$(EXEEXT)$$//'`; \
>-	  if test -f $$p \
>+?LIBTOOL?	  p1=`echo $$p|sed 's/$(LT_EXEEXT)$$//'`; \
>+?LIBTOOL?	  p2=`echo $$p1|sed 's/$$/$(LT_EXEEXT)/'`; \
>+?!LIBTOOL?	  p1=`echo $$p|sed 's/$(EXEEXT)$$//'`; \
>+?!LIBTOOL?	  p2=`echo $$p1|sed 's/$$/$(EXEEXT)/'`; \
>+	  if test -f $$p2 \
> ?LIBTOOL?	     || test -f $$p1 \
> 	  ; then \
> ## Compute basename of source file.  Unless this is a nobase_ target, we
>@@ -45,16 +48,17 @@
> ## not '$(DESTDIR)$(%NDIR%dir)/python/foo.yo'.
> ## However in all cases $(transform) applies only to the basename,
> ## so we have to strip the directory part.
>-	    f=`echo "$$p1" | sed 's,^.*/,,;$(transform);s/$$/$(EXEEXT)/'`; \
>+?LIBTOOL?	    f=`echo "$$p1" | sed 's,^.*/,,;$(transform);s/$$/$(LT_EXEEXT)/'`; \
>+?!LIBTOOL?	    f=`echo "$$p1" | sed 's,^.*/,,;$(transform);s/$$/$(EXEEXT)/'`; \
> ## Prepend the directory part if nobase_ is used.
> ?!BASE?	    f=`echo "$$p1" | sed 's|[^/]*$$||'`"$$f"; \
> ## Note that we explicitly set the libtool mode.  This avoids any
> ## lossage if the install program doesn't have a name that libtool
> ## expects.
>-?LIBTOOL?	   echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) --mode=install $(%DIR%PROGRAMS_INSTALL) $$p $(DESTDIR)$(%NDIR%dir)/$$f"; \
>-?LIBTOOL?	   $(INSTALL_PROGRAM_ENV) $(LIBTOOL) --mode=install $(%DIR%PROGRAMS_INSTALL) $$p $(DESTDIR)$(%NDIR%dir)/$$f || exit 1; \
>-?!LIBTOOL?	   echo " $(INSTALL_PROGRAM_ENV) $(%DIR%PROGRAMS_INSTALL) $$p $(DESTDIR)$(%NDIR%dir)/$$f"; \
>-?!LIBTOOL?	   $(INSTALL_PROGRAM_ENV) $(%DIR%PROGRAMS_INSTALL) $$p $(DESTDIR)$(%NDIR%dir)/$$f || exit 1; \
>+?LIBTOOL?	   echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) --mode=install $(%DIR%PROGRAMS_INSTALL) $$p2 $(DESTDIR)$(%NDIR%dir)/$$f"; \
>+?LIBTOOL?	   $(INSTALL_PROGRAM_ENV) $(LIBTOOL) --mode=install $(%DIR%PROGRAMS_INSTALL) $$p2 $(DESTDIR)$(%NDIR%dir)/$$f || exit 1; \
>+?!LIBTOOL?	   echo " $(INSTALL_PROGRAM_ENV) $(%DIR%PROGRAMS_INSTALL) $$p2 $(DESTDIR)$(%NDIR%dir)/$$f"; \
>+?!LIBTOOL?	   $(INSTALL_PROGRAM_ENV) $(%DIR%PROGRAMS_INSTALL) $$p2 $(DESTDIR)$(%NDIR%dir)/$$f || exit 1; \
> 	  else :; fi; \
> 	done
> endif %?INSTALL%
>@@ -70,7 +74,8 @@
> 	@$(NORMAL_UNINSTALL)
> 	@list='$(%DIR%_PROGRAMS)'; for p in $$list; do \
> ## Remove any leading directory before applying $(transform).
>-	  f=`echo "$$p" | sed 's,^.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/'`; \
>+?LIBTOOL?	  f=`echo "$$p" | sed 's,^.*/,,;s/$(LT_EXEEXT)$$//;$(transform);s/$$/$(LT_EXEEXT)/'`; \
>+?!LIBTOOL?	  f=`echo "$$p" | sed 's,^.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/'`; \
> ## Prepend the directory part if nobase_ is used.
> ?!BASE?	  f=`echo "$$p" | sed 's|[^/]*$$||'`"$$f"; \
> 	  echo " rm -f $(DESTDIR)$(%NDIR%dir)/$$f"; \
>@@ -95,9 +100,10 @@
> ## FIXME: In the future (i.e., when it works) it would be nice to delegate
> ## this task to `libtool --mode=clean'.
> ?LIBTOOL?	@list='$(%DIR%_PROGRAMS)'; for p in $$list; do \
>-?LIBTOOL?	  f=`echo $$p|sed 's/$(EXEEXT)$$//'`; \
>-?LIBTOOL?	  echo " rm -f $$p $$f"; \
>-?LIBTOOL?	  rm -f $$p $$f ; \
>+?LIBTOOL?	  f1=`echo $$p|sed 's/$(LT_EXEEXT)$$//'`; \
>+?LIBTOOL?	  f2=`echo $$f1|sed 's/$$/$(LT_EXEEXT)/'`; \
>+?LIBTOOL?	  echo " rm -f $$f1 $$f2"; \
>+?LIBTOOL?	  rm -f $$f1 $$f2 ; \
> ?LIBTOOL?	done
> 
> 
>@@ -116,7 +122,8 @@
> 	  esac; \
> ## Strip the directory and $(EXEEXT) before applying $(transform).
> 	  f=`echo "$$p" | \
>-	     sed 's,^.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/'`; \
>+?LIBTOOL?	     sed 's,^.*/,,;s/$(LT_EXEEXT)$$//;$(transform);s/$$/$(LT_EXEEXT)/'`; \
>+?!LIBTOOL?	     sed 's,^.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/'`; \
> ## Insert the directory back if nobase_ is used.
> ?!BASE?	  f=`echo "$$p" | sed 's|[^/]*$$||'`"$$f"; \
> 	  for opt in --help --version; do \
>  
>
>------------------------------------------------------------------------
>
>? .build
>? .inst
>? .sinst
>? COPYING
>? CYGWIN-PATCHES
>? INSTALL
>? install-sh
>? missing
>? mkinstalldirs
>? libltdl/config-h.in
>Index: libtool.m4
>===================================================================
>RCS file: /cvsroot/libtool/libtool/libtool.m4,v
>retrieving revision 1.287
>diff -u -u -r1.287 libtool.m4
>--- libtool.m4	31 Dec 2002 05:43:23 -0000	1.287
>+++ libtool.m4	6 Jan 2003 07:34:06 -0000
>@@ -109,6 +109,7 @@
> # Autoconf 2.13's AC_OBJEXT and AC_EXEEXT macros only works for C compilers!
> AC_REQUIRE([AC_OBJEXT])dnl
> AC_REQUIRE([AC_EXEEXT])dnl
>+AC_REQUIRE([_LT_EXEEXT])dnl
> dnl
> 
> AC_LIBTOOL_SYS_MAX_CMD_LEN
>@@ -5510,6 +5511,17 @@
> AC_DEFUN([LT_AC_PROG_RC],
> [AC_CHECK_TOOL(RC, windres, no)
> ])
>+
>+AC_DEFUN([_LT_EXEEXT],
>+[lt_exeext=$ac_exeext
>+AC_SUBST([LT_EXEEXT], [$lt_exeext])dnl
>+# Don't allow calls to AC_EXEEXT again
>+define([AC_EXEEXT], [])
>+# keep definition of $ac_exeext, but insure that EXEEXT 
>+# is empty in makefiles
>+ac_cv_exeext=
>+EXEEXT=
>+])# _LT_EXEEXT
> 
> ############################################################
> # NOTE: This macro has been submitted for inclusion into   #
>Index: tests/Makefile.am
>===================================================================
>RCS file: /cvsroot/libtool/libtool/tests/Makefile.am,v
>retrieving revision 1.32
>diff -u -u -r1.32 Makefile.am
>--- tests/Makefile.am	18 Nov 2002 18:59:44 -0000	1.32
>+++ tests/Makefile.am	6 Jan 2003 07:34:07 -0000
>@@ -75,7 +75,8 @@
> TESTS_ENVIRONMENT = MAKE="$(MAKE)" CC="$(CC)" CFLAGS="$(CFLAGS)" \
> 	CPPFLAGS="$(CPPFLAGS)" LD="$(LD)" LDFLAGS="$(LDFLAGS)" \
> 	LIBS="$(LIBS)" LN_S="$(LN_S)" NM="$(NM)" RANLIB="$(RANLIB)" \
>-	OBJEXT="$(OBJEXT)" EXEEXT="$(EXEEXT)" FFLAGS="$(FFLAGS)" 
>+	OBJEXT="$(OBJEXT)" EXEEXT="$(EXEEXT)" LT_EXEEXT="$(LT_EXEEXT)" \
>+	FFLAGS="$(FFLAGS)" 
> 
> EXTRA_DIST = defs $(COMMON_TESTS) $(CXX_TESTS) $(F77_TESTS)
> 
>Index: tests/build-relink.test
>===================================================================
>RCS file: /cvsroot/libtool/libtool/tests/build-relink.test,v
>retrieving revision 1.13
>diff -u -u -r1.13 build-relink.test
>--- tests/build-relink.test	19 Nov 2002 09:42:39 -0000	1.13
>+++ tests/build-relink.test	6 Jan 2003 07:34:07 -0000
>@@ -105,8 +105,8 @@
> fi
> 
> if test "$shlibpath_overrides_runpath" != yes; then
>-  rm -f $objdir/lt-hell$EXEEXT || exit 1
>-  cp $objdir/hell$EXEEXT $objdir/lt-hell$EXEEXT || exit 1
>+  rm -f $objdir/lt-hell$LT_EXEEXT || exit 1
>+  cp $objdir/hell$LT_EXEEXT $objdir/lt-hell$LT_EXEEXT || exit 1
>   echo "running ../demo/hell with installed libhello.la"
>   if ./hell; then
>     echo "Worked, as expected"
>@@ -114,7 +114,7 @@
>     echo "shlibpath_overrides_runpath should be set to yes"
>     status=1
>   fi
>-  rm -f $objdir/lt-hell$EXEEXT
>+  rm -f $objdir/lt-hell$LT_EXEEXT
> fi
> 
> exit $status
>Index: tests/dryrun.test
>===================================================================
>RCS file: /cvsroot/libtool/libtool/tests/dryrun.test,v
>retrieving revision 1.9
>diff -u -u -r1.9 dryrun.test
>--- tests/dryrun.test	3 Mar 2002 03:19:55 -0000	1.9
>+++ tests/dryrun.test	6 Jan 2003 07:34:08 -0000
>@@ -89,7 +89,7 @@
> 
> echo "= Running $make uninstall in ../mdemo (dry run)"
> # Libtool does not uninstall the programs, remove them first
>-rm -f $prefix/bin/mdemo$EXEEXT $prefix/bin/mdemo_static$EXEEXT
>+rm -f $prefix/bin/mdemo$LT_EXEEXT $prefix/bin/mdemo_static$LT_EXEEXT
> ls -l . $objdir > $before
> ls -lR $prefix >> $before
> force_dry_run=yes $make uninstall 1>&2 || exit $?
>Index: tests/noinst-link.test
>===================================================================
>RCS file: /cvsroot/libtool/libtool/tests/noinst-link.test,v
>retrieving revision 1.3
>diff -u -u -r1.3 noinst-link.test
>--- tests/noinst-link.test	3 Mar 2002 03:19:55 -0000	1.3
>+++ tests/noinst-link.test	6 Jan 2003 07:34:08 -0000
>@@ -22,14 +22,14 @@
> cd ../demo || exit 77
> 
> echo "removing libhello.la and hell from ../demo"
>-rm -f libhello.la hell$EXEEXT
>+rm -f libhello.la hell$LT_EXEEXT
> 
> echo "linking hell with a broken ../demo/libhello.la"
>-if $make hell$EXEEXT libhello_la_OBJECTS=hello.lo; then
>+if $make hell$LT_EXEEXT libhello_la_OBJECTS=hello.lo; then
>   echo "= Succeeded: this means the installed library was used, which is wrong"
>   status=1
> fi
> 
>-rm -f libhello.la hell$EXEEXT
>+rm -f libhello.la hell$LT_EXEEXT
> 
> exit $status
>
Hi,
This is a change I was waiting for a long time now. Great!
No more endless installs and fights with the libtool.
Thanks.

Regards.
Michael Bester.






--
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/

Solving the "relink exe's" libtool problem

[Charles Wilson]

[-- Attachment #1: Type: text/plain, Size: 4382 bytes --]

[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

[-- Attachment #2: automake.changelog --]
[-- Type: text/plain, Size: 539 bytes --]

2003-01-05  Charles Wilson  <cwilson@ece.gatech.edu>

	* lib/am/program.am: when %?LIBTOOL%, use $(LT_EXEEXT)
	not %EXEEXT%
	* lib/am/progs.am (install-%DIR%PROGRAMS): when %?LIBTOOL%,
	use $(LT_EXEEXT) not $(EXEEXT).  Insure that we test for 
	both foo and foo$[LT_]EXEEXT.  Insure that we install 
	foo$([LT_]EXEEXT) and not foo.
	(uninstall-%DIR%PROGRAMS): when %?LIBTOOL%, use 
	$(LT_EXEEXT) not $(EXEEXT)
	(clean-%DIR%PROGRAMS): when %?LIBTOOL%, use $(LT_EXEEXT),
	not $(EXEEXT). Insure that we remove both foo$(LT_EXEEXT)
	and foo.


[-- Attachment #3: libtool.changelog --]
[-- Type: text/plain, Size: 317 bytes --]

2002-01-05  Charles Wilson  <cwilson@ece.gatech.edu>

	* libtool.m4 (_LT_EXEEXT): new function
	(AC_LIBTOOL_SETUP): call it
	* tests/Makefile.am: pass $(LT_EXEEXT) on to
	TEST_ENVIRONMENT
	* tests/build-relink.test: use $(LT_EXEEXT) 
	instead of $(EXEEXT)
	* tests/dryrun.test: ditto
	* tests/noinst-link.test: ditto

[-- Attachment #4: automake.patch --]
[-- Type: text/plain, Size: 5234 bytes --]

diff -u automake-1.7.2-orig/lib/am/program.am automake-1.7.2/lib/am/program.am
--- automake-1.7.2-orig/lib/am/program.am	2002-12-06 04:53:18.000000000 -0500
+++ automake-1.7.2/lib/am/program.am	2003-01-05 18:09:01.000000000 -0500
@@ -15,6 +15,12 @@
 ## along with this program; if not, write to the Free Software
 ## Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
 ## 02111-1307, USA.
+if %?LIBTOOL%
+%PROGRAM%%EXEEXT%: $(%XPROGRAM%_OBJECTS) $(%XPROGRAM%_DEPENDENCIES) %DIRSTAMP%
+## take care of wrapper script, static executable, and dynamic executable
+	@rm -f %PROGRAM% %PROGRAM%$(LT_EXEEXT) .libs/%PROGRAM%$(LT_EXEEXT) _libs/%PROGRAM%$(LT_EXEEXT)
+	$(%XLINK%) $(%XPROGRAM%_LDFLAGS) $(%XPROGRAM%_OBJECTS) $(%XPROGRAM%_LDADD) $(LIBS)
+else !%?LIBTOOL%
 %PROGRAM%%EXEEXT%: $(%XPROGRAM%_OBJECTS) $(%XPROGRAM%_DEPENDENCIES) %DIRSTAMP%
 ## Remove program before linking.  Otherwise the link will fail if the
 ## program is running somewhere.  FIXME: this could be a loss if
@@ -23,3 +29,4 @@
 ## systems.
 	@rm -f %PROGRAM%%EXEEXT%
 	$(%XLINK%) $(%XPROGRAM%_LDFLAGS) $(%XPROGRAM%_OBJECTS) $(%XPROGRAM%_LDADD) $(LIBS)
+endif !%?LIBTOOL%
diff -u automake-1.7.2-orig/lib/am/progs.am automake-1.7.2/lib/am/progs.am
--- automake-1.7.2-orig/lib/am/progs.am	2002-12-06 04:53:19.000000000 -0500
+++ automake-1.7.2/lib/am/progs.am	2003-01-05 18:43:30.000000000 -0500
@@ -36,8 +36,11 @@
 	@list='$(%DIR%_PROGRAMS)'; for p in $$list; do \
 ## On Cygwin with libtool test won't see `foo.exe' but instead `foo'.
 ## So we check for both.
-	  p1=`echo $$p|sed 's/$(EXEEXT)$$//'`; \
-	  if test -f $$p \
+?LIBTOOL?	  p1=`echo $$p|sed 's/$(LT_EXEEXT)$$//'`; \
+?LIBTOOL?	  p2=`echo $$p1|sed 's/$$/$(LT_EXEEXT)/'`; \
+?!LIBTOOL?	  p1=`echo $$p|sed 's/$(EXEEXT)$$//'`; \
+?!LIBTOOL?	  p2=`echo $$p1|sed 's/$$/$(EXEEXT)/'`; \
+	  if test -f $$p2 \
 ?LIBTOOL?	     || test -f $$p1 \
 	  ; then \
 ## Compute basename of source file.  Unless this is a nobase_ target, we
@@ -45,16 +48,17 @@
 ## not '$(DESTDIR)$(%NDIR%dir)/python/foo.yo'.
 ## However in all cases $(transform) applies only to the basename,
 ## so we have to strip the directory part.
-	    f=`echo "$$p1" | sed 's,^.*/,,;$(transform);s/$$/$(EXEEXT)/'`; \
+?LIBTOOL?	    f=`echo "$$p1" | sed 's,^.*/,,;$(transform);s/$$/$(LT_EXEEXT)/'`; \
+?!LIBTOOL?	    f=`echo "$$p1" | sed 's,^.*/,,;$(transform);s/$$/$(EXEEXT)/'`; \
 ## Prepend the directory part if nobase_ is used.
 ?!BASE?	    f=`echo "$$p1" | sed 's|[^/]*$$||'`"$$f"; \
 ## Note that we explicitly set the libtool mode.  This avoids any
 ## lossage if the install program doesn't have a name that libtool
 ## expects.
-?LIBTOOL?	   echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) --mode=install $(%DIR%PROGRAMS_INSTALL) $$p $(DESTDIR)$(%NDIR%dir)/$$f"; \
-?LIBTOOL?	   $(INSTALL_PROGRAM_ENV) $(LIBTOOL) --mode=install $(%DIR%PROGRAMS_INSTALL) $$p $(DESTDIR)$(%NDIR%dir)/$$f || exit 1; \
-?!LIBTOOL?	   echo " $(INSTALL_PROGRAM_ENV) $(%DIR%PROGRAMS_INSTALL) $$p $(DESTDIR)$(%NDIR%dir)/$$f"; \
-?!LIBTOOL?	   $(INSTALL_PROGRAM_ENV) $(%DIR%PROGRAMS_INSTALL) $$p $(DESTDIR)$(%NDIR%dir)/$$f || exit 1; \
+?LIBTOOL?	   echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) --mode=install $(%DIR%PROGRAMS_INSTALL) $$p2 $(DESTDIR)$(%NDIR%dir)/$$f"; \
+?LIBTOOL?	   $(INSTALL_PROGRAM_ENV) $(LIBTOOL) --mode=install $(%DIR%PROGRAMS_INSTALL) $$p2 $(DESTDIR)$(%NDIR%dir)/$$f || exit 1; \
+?!LIBTOOL?	   echo " $(INSTALL_PROGRAM_ENV) $(%DIR%PROGRAMS_INSTALL) $$p2 $(DESTDIR)$(%NDIR%dir)/$$f"; \
+?!LIBTOOL?	   $(INSTALL_PROGRAM_ENV) $(%DIR%PROGRAMS_INSTALL) $$p2 $(DESTDIR)$(%NDIR%dir)/$$f || exit 1; \
 	  else :; fi; \
 	done
 endif %?INSTALL%
@@ -70,7 +74,8 @@
 	@$(NORMAL_UNINSTALL)
 	@list='$(%DIR%_PROGRAMS)'; for p in $$list; do \
 ## Remove any leading directory before applying $(transform).
-	  f=`echo "$$p" | sed 's,^.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/'`; \
+?LIBTOOL?	  f=`echo "$$p" | sed 's,^.*/,,;s/$(LT_EXEEXT)$$//;$(transform);s/$$/$(LT_EXEEXT)/'`; \
+?!LIBTOOL?	  f=`echo "$$p" | sed 's,^.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/'`; \
 ## Prepend the directory part if nobase_ is used.
 ?!BASE?	  f=`echo "$$p" | sed 's|[^/]*$$||'`"$$f"; \
 	  echo " rm -f $(DESTDIR)$(%NDIR%dir)/$$f"; \
@@ -95,9 +100,10 @@
 ## FIXME: In the future (i.e., when it works) it would be nice to delegate
 ## this task to `libtool --mode=clean'.
 ?LIBTOOL?	@list='$(%DIR%_PROGRAMS)'; for p in $$list; do \
-?LIBTOOL?	  f=`echo $$p|sed 's/$(EXEEXT)$$//'`; \
-?LIBTOOL?	  echo " rm -f $$p $$f"; \
-?LIBTOOL?	  rm -f $$p $$f ; \
+?LIBTOOL?	  f1=`echo $$p|sed 's/$(LT_EXEEXT)$$//'`; \
+?LIBTOOL?	  f2=`echo $$f1|sed 's/$$/$(LT_EXEEXT)/'`; \
+?LIBTOOL?	  echo " rm -f $$f1 $$f2"; \
+?LIBTOOL?	  rm -f $$f1 $$f2 ; \
 ?LIBTOOL?	done
 
 
@@ -116,7 +122,8 @@
 	  esac; \
 ## Strip the directory and $(EXEEXT) before applying $(transform).
 	  f=`echo "$$p" | \
-	     sed 's,^.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/'`; \
+?LIBTOOL?	     sed 's,^.*/,,;s/$(LT_EXEEXT)$$//;$(transform);s/$$/$(LT_EXEEXT)/'`; \
+?!LIBTOOL?	     sed 's,^.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/'`; \
 ## Insert the directory back if nobase_ is used.
 ?!BASE?	  f=`echo "$$p" | sed 's|[^/]*$$||'`"$$f"; \
 	  for opt in --help --version; do \

[-- Attachment #5: libtool.patch --]
[-- Type: text/plain, Size: 4280 bytes --]

? .build
? .inst
? .sinst
? COPYING
? CYGWIN-PATCHES
? INSTALL
? install-sh
? missing
? mkinstalldirs
? libltdl/config-h.in
Index: libtool.m4
===================================================================
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.287
diff -u -u -r1.287 libtool.m4
--- libtool.m4	31 Dec 2002 05:43:23 -0000	1.287
+++ libtool.m4	6 Jan 2003 07:34:06 -0000
@@ -109,6 +109,7 @@
 # Autoconf 2.13's AC_OBJEXT and AC_EXEEXT macros only works for C compilers!
 AC_REQUIRE([AC_OBJEXT])dnl
 AC_REQUIRE([AC_EXEEXT])dnl
+AC_REQUIRE([_LT_EXEEXT])dnl
 dnl
 
 AC_LIBTOOL_SYS_MAX_CMD_LEN
@@ -5510,6 +5511,17 @@
 AC_DEFUN([LT_AC_PROG_RC],
 [AC_CHECK_TOOL(RC, windres, no)
 ])
+
+AC_DEFUN([_LT_EXEEXT],
+[lt_exeext=$ac_exeext
+AC_SUBST([LT_EXEEXT], [$lt_exeext])dnl
+# Don't allow calls to AC_EXEEXT again
+define([AC_EXEEXT], [])
+# keep definition of $ac_exeext, but insure that EXEEXT 
+# is empty in makefiles
+ac_cv_exeext=
+EXEEXT=
+])# _LT_EXEEXT
 
 ############################################################
 # NOTE: This macro has been submitted for inclusion into   #
Index: tests/Makefile.am
===================================================================
RCS file: /cvsroot/libtool/libtool/tests/Makefile.am,v
retrieving revision 1.32
diff -u -u -r1.32 Makefile.am
--- tests/Makefile.am	18 Nov 2002 18:59:44 -0000	1.32
+++ tests/Makefile.am	6 Jan 2003 07:34:07 -0000
@@ -75,7 +75,8 @@
 TESTS_ENVIRONMENT = MAKE="$(MAKE)" CC="$(CC)" CFLAGS="$(CFLAGS)" \
 	CPPFLAGS="$(CPPFLAGS)" LD="$(LD)" LDFLAGS="$(LDFLAGS)" \
 	LIBS="$(LIBS)" LN_S="$(LN_S)" NM="$(NM)" RANLIB="$(RANLIB)" \
-	OBJEXT="$(OBJEXT)" EXEEXT="$(EXEEXT)" FFLAGS="$(FFLAGS)" 
+	OBJEXT="$(OBJEXT)" EXEEXT="$(EXEEXT)" LT_EXEEXT="$(LT_EXEEXT)" \
+	FFLAGS="$(FFLAGS)" 
 
 EXTRA_DIST = defs $(COMMON_TESTS) $(CXX_TESTS) $(F77_TESTS)
 
Index: tests/build-relink.test
===================================================================
RCS file: /cvsroot/libtool/libtool/tests/build-relink.test,v
retrieving revision 1.13
diff -u -u -r1.13 build-relink.test
--- tests/build-relink.test	19 Nov 2002 09:42:39 -0000	1.13
+++ tests/build-relink.test	6 Jan 2003 07:34:07 -0000
@@ -105,8 +105,8 @@
 fi
 
 if test "$shlibpath_overrides_runpath" != yes; then
-  rm -f $objdir/lt-hell$EXEEXT || exit 1
-  cp $objdir/hell$EXEEXT $objdir/lt-hell$EXEEXT || exit 1
+  rm -f $objdir/lt-hell$LT_EXEEXT || exit 1
+  cp $objdir/hell$LT_EXEEXT $objdir/lt-hell$LT_EXEEXT || exit 1
   echo "running ../demo/hell with installed libhello.la"
   if ./hell; then
     echo "Worked, as expected"
@@ -114,7 +114,7 @@
     echo "shlibpath_overrides_runpath should be set to yes"
     status=1
   fi
-  rm -f $objdir/lt-hell$EXEEXT
+  rm -f $objdir/lt-hell$LT_EXEEXT
 fi
 
 exit $status
Index: tests/dryrun.test
===================================================================
RCS file: /cvsroot/libtool/libtool/tests/dryrun.test,v
retrieving revision 1.9
diff -u -u -r1.9 dryrun.test
--- tests/dryrun.test	3 Mar 2002 03:19:55 -0000	1.9
+++ tests/dryrun.test	6 Jan 2003 07:34:08 -0000
@@ -89,7 +89,7 @@
 
 echo "= Running $make uninstall in ../mdemo (dry run)"
 # Libtool does not uninstall the programs, remove them first
-rm -f $prefix/bin/mdemo$EXEEXT $prefix/bin/mdemo_static$EXEEXT
+rm -f $prefix/bin/mdemo$LT_EXEEXT $prefix/bin/mdemo_static$LT_EXEEXT
 ls -l . $objdir > $before
 ls -lR $prefix >> $before
 force_dry_run=yes $make uninstall 1>&2 || exit $?
Index: tests/noinst-link.test
===================================================================
RCS file: /cvsroot/libtool/libtool/tests/noinst-link.test,v
retrieving revision 1.3
diff -u -u -r1.3 noinst-link.test
--- tests/noinst-link.test	3 Mar 2002 03:19:55 -0000	1.3
+++ tests/noinst-link.test	6 Jan 2003 07:34:08 -0000
@@ -22,14 +22,14 @@
 cd ../demo || exit 77
 
 echo "removing libhello.la and hell from ../demo"
-rm -f libhello.la hell$EXEEXT
+rm -f libhello.la hell$LT_EXEEXT
 
 echo "linking hell with a broken ../demo/libhello.la"
-if $make hell$EXEEXT libhello_la_OBJECTS=hello.lo; then
+if $make hell$LT_EXEEXT libhello_la_OBJECTS=hello.lo; then
   echo "= Succeeded: this means the installed library was used, which is wrong"
   status=1
 fi
 
-rm -f libhello.la hell$EXEEXT
+rm -f libhello.la hell$LT_EXEEXT
 
 exit $status

[-- Attachment #6: relinkprog-demo.tar.bz2 --]
[-- Type: application/octet-stream, Size: 2211 bytes --]

[-- Attachment #7: Type: text/plain, Size: 214 bytes --]

--
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/

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

[Alexandre Duret-Lutz]

>>> "Chuck" == Charles Wilson <cwilson@ece.gatech.edu> writes:

[...]

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

 Chuck> So, you end up with:

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

Any way lt-foo.c could go into .libs/?  Or just be erased after
foo.exe has been built?  Maybe both?

Also I if you don't move `foo' to `.libs/' I think you
should ensure that `libtool --mode=clean rm -f foo.exe' 
erases `foo'.  (Or does Cygwin's `rm' erase both at once?)

Right now Automake doesn't use `--mode=clean'.  Maybe Automake
1.8 could start doing this so we don't have to hardcode this
sort of knowledge.

[...]
-- 
Alexandre Duret-Lutz

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

[Earnie Boyd]

Charles Wilson wrote:
> 
> 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...
> 

Yes MSVCRT.DLL contains both exec and spawn sets of functions.  Yes the 
parent environment is inherited by the child.  So, the stub should be 
able to work for either environment.

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

Sorry to hear that. :(

Earnie.

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

[Earnie Boyd]

Charles Wilson wrote:
> 
> 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.
> 

This can be resolved by ``. ./foo.'' instead for the cygwin/mingw hosts.

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

[Charles Wilson]

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

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

[Charles Wilson]

[-- Attachment #1: Type: text/plain, Size: 4894 bytes --]

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

[-- Attachment #2: libtool-relinkexe2.changelog --]
[-- Type: text/plain, Size: 353 bytes --]

2003-01-11  Charles Wilson  <cwilson@ece.gatech.edu>

	* ltmain.in: add code for a binary wrapper
	to use with uninstalled executables on cygwin/mingw.
	To work around a feature of the cygwin/MSYS shell,
	temporarily create a copy of the shell wrapper under
	a different name before sourcing it (otherwise,
	the binary wrapper gets sourced, instead...)

[-- Attachment #3: libtool-relinkexe2.patch --]
[-- Type: text/plain, Size: 6118 bytes --]

Index: ltmain.in
===================================================================
RCS file: /cvsroot/libtool/libtool/ltmain.in,v
retrieving revision 1.318
diff -u -u -r1.318 ltmain.in
--- ltmain.in	1 Jan 2003 01:57:47 -0000	1.318
+++ ltmain.in	11 Jan 2003 20:00:37 -0000
@@ -4284,6 +4284,201 @@
 	    outputname=`echo $outputname|${SED} 's,.exe$,,'` ;;
 	  *) exeext= ;;
 	esac
+	case $host in
+	  *cygwin* | *mingw* )
+	    cwrappersource=`echo lt-$output|${SED} 's,$,.c,'`
+	    cwrapper=`echo $output|${SED} 's,$,.exe,'`
+	    $rm $cwrappersource $cwrapper
+	    trap "$fm $cwrappersource $cwrapper; exit 1" 1 2 15
+
+	    cat > $cwrappersource <<EOF
+
+/* $cwrappersource - temporary wrapper executable for $objdir/$outputname
+   Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP
+
+   The $output program cannot be directly executed until all the libtool
+   libraries that it depends on are installed.
+   
+   This wrapper executable should never be moved out of the build directory.
+   If it is, it will not operate correctly.
+
+   Currently, it simply execs the wrapper *script* "/bin/sh $output",
+   but could eventually absorb all of the scripts functionality and
+   exec $objdir/$outputname directly.
+*/
+EOF
+	    cat >> $cwrappersource<<"EOF"
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <malloc.h>
+#include <stdarg.h>
+#include <assert.h>
+
+#if defined(PATH_MAX)
+# define LT_PATHMAX PATH_MAX
+#elif defined(MAXPATHLEN)
+# define LT_PATHMAX MAXPATHLEN
+#else
+# define LT_PATHMAX 1024
+#endif
+
+#ifndef DIR_SEPARATOR
+#define DIR_SEPARATOR '/'
+#endif
+
+#if defined (_WIN32) || defined (__MSDOS__) || defined (__DJGPP__) || \
+  defined (__OS2__)
+#define HAVE_DOS_BASED_FILE_SYSTEM
+#ifndef DIR_SEPARATOR_2 
+#define DIR_SEPARATOR_2 '\\'
+#endif
+#endif
+
+#ifndef DIR_SEPARATOR_2
+# define IS_DIR_SEPARATOR(ch) ((ch) == DIR_SEPARATOR)
+#else /* DIR_SEPARATOR_2 */
+# define IS_DIR_SEPARATOR(ch) \
+        (((ch) == DIR_SEPARATOR) || ((ch) == DIR_SEPARATOR_2))
+#endif /* DIR_SEPARATOR_2 */
+
+#define XMALLOC(type, num)      ((type *) xmalloc ((num) * sizeof(type)))
+#define XFREE(stale) do { \
+  if (stale) { free ((void *) stale); stale = 0; } \
+} while (0)
+
+const char *program_name = NULL;
+
+void * xmalloc (size_t num);
+char * xstrdup (const char *string);
+char * basename (const char *name);
+char * fnqualify(const char *path);
+char * strendzap(char *str, const char *pat);
+void lt_fatal (const char *message, ...);
+
+int
+main (int argc, char *argv[])
+{
+  char *full;
+
+  program_name = (char *) xstrdup ((char *) basename (argv[0]));
+  full = fnqualify(argv[0]);
+  /* we know the script has the same name, without the .exe */
+  /* so make sure full doesn't end in .exe */
+  strendzap(full,".exe"); 
+  execl("/bin/sh","/bin/sh",full,NULL);
+}
+
+void *
+xmalloc (size_t num)
+{
+  void * p = (void *) malloc (num);
+  if (!p)
+    lt_fatal ("Memory exhausted");
+
+  return p;
+}
+
+char * 
+xstrdup (const char *string)
+{
+  return string ? strcpy ((char *) xmalloc (strlen (string) + 1), string) : NULL
+;
+}
+
+char *
+basename (const char *name)
+{
+  const char *base;
+
+#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
+  /* Skip over the disk name in MSDOS pathnames. */
+  if (isalpha (name[0]) && name[1] == ':') 
+    name += 2;
+#endif
+
+  for (base = name; *name; name++)
+    if (IS_DIR_SEPARATOR (*name))
+      base = name + 1;
+  return (char *) base;
+}
+
+char * 
+fnqualify(const char *path)
+{
+  size_t size;
+  char *p;
+  char tmp[LT_PATHMAX + 1];
+
+  assert(path != NULL);
+
+  /* Is it qualified already? */
+#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
+  if (isalpha (path[0]) && path[1] == ':')
+    return xstrdup (path);
+#endif
+  if (IS_DIR_SEPARATOR (path[0]))
+    return xstrdup (path);
+
+  /* prepend the current directory */
+  /* doesn't handle '~' */
+  if (getcwd (tmp, LT_PATHMAX) == NULL)
+    lt_fatal ("getcwd failed");
+  size = strlen(tmp) + 1 + strlen(path) + 1; /* +2 for '/' and '\0' */
+  p = XMALLOC(char, size);
+  sprintf(p, "%s%c%s", tmp, DIR_SEPARATOR, path);
+  return p;
+}
+
+char *
+strendzap(char *str, const char *pat) 
+{
+  size_t len, patlen;
+
+  assert(str != NULL);
+  assert(pat != NULL);
+
+  len = strlen(str);
+  patlen = strlen(pat);
+
+  if (patlen <= len)
+  {
+    str += len - patlen;
+    if (strcmp(str, pat) == 0)
+      *str = '\0';
+  }
+  return str;
+}
+
+static void
+lt_error_core (int exit_status, const char * mode, 
+          const char * message, va_list ap)
+{
+  fprintf (stderr, "%s: %s: ", program_name, mode);
+  vfprintf (stderr, message, ap);
+  fprintf (stderr, ".\n");
+
+  if (exit_status >= 0)
+    exit (exit_status);
+}
+
+void
+lt_fatal (const char *message, ...)
+{
+  va_list ap;
+  va_start (ap, message);
+  lt_error_core (EXIT_FAILURE, "FATAL", message, ap);
+  va_end (ap);
+}
+EOF
+	  # 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
+	  ;;
+	esac
 	$rm $output
 	trap "$rm $output; exit 1" 1 2 15
 
@@ -5066,8 +5261,12 @@
 
 	  # If there is no directory component, then add one.
 	  case $file in
-	  */* | *\\*) . $wrapper ;;
-	  *) . ./$wrapper ;;
+	  */* | *\\*) cp ${wrapper} ${wrapper}-lt.sh 
+	    . ${wrapper}-lt.sh
+	    $rm -f ${wrapper}-lt.sh ;;
+	  *) cp ./${wrapper} ./${wrapper}-lt.sh 
+	    . ./${wrapper}-lt.sh
+	    $rm -f ${wrapper}-lt.sh ;;
 	  esac
 
 	  # Check the variables that should have been set.
@@ -5097,8 +5296,12 @@
 	  relink_command=
 	  # If there is no directory component, then add one.
 	  case $file in
-	  */* | *\\*) . $file ;;
-	  *) . ./$file ;;
+	  */* | *\\*) cp ${wrapper} ${wrapper}-lt.sh 
+	    . ${wrapper}-lt.sh
+	    $rm -f ${wrapper}-lt.sh ;;
+	  *) cp ./${wrapper} ./${wrapper}-lt.sh 
+	    . ./${wrapper}-lt.sh
+	    $rm -f ${wrapper}-lt.sh ;;
 	  esac
 
 	  outputname=

Blue screen of death on cygwin+win98+./configure

[Bhiksha Raj]

Hi All,

Im trying to install TeXmacs on my win98+cygwin laptop.
First I installed the binaries for guile from the cygwin setup
(I have XFree and Tex and all associated libs already)
downloaded TeXmacs sources, ran ./configure and then
gave a "make".
I got  the blue screen of death (BSD).
After iterating through several BSDs, I hunted on the web
and found a site that said that static linkages were a problem with
the latest guile and that I must install guile 1.4.1. So I uninstalled
guile,
downloaded the sources for guile 1.4.1, untarred them and
ran
./configure --disable-shared

It runs through several checks, but never completes - insted it
gives me at some point it simply gives me the blue screen of death.
This time around Im not even getting past configure.

Im not sure what to do now.
Any advice at all would be greatly appreciated.

Much thanks
Bhiksha
bhiksha@merl.com

P.S: Ive hunted on the web and faqs for answers and couldnt find
any.

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

[Alexandre Duret-Lutz]

>>> "Chuck" == Charles Wilson <cwilson@ece.gatech.edu> 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

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

[Alexandre Duret-Lutz]

>>> "Chuck" == Charles Wilson <cwilson@ece.gatech.edu> writes:

[...]

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

Yes.  Sigh.

[...]

 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.

[...]

-- 
Alexandre Duret-Lutz

Re: Blue screen of death on cygwin+win98+./configure

[Igor Pechtchanski]

On Sun, 12 Jan 2003, Bhiksha Raj wrote:

> Hi All,
>
> Im trying to install TeXmacs on my win98+cygwin laptop.
> First I installed the binaries for guile from the cygwin setup
> (I have XFree and Tex and all associated libs already)
> downloaded TeXmacs sources, ran ./configure and then
> gave a "make".
> I got  the blue screen of death (BSD).
> After iterating through several BSDs, I hunted on the web
> and found a site that said that static linkages were a problem with
> the latest guile and that I must install guile 1.4.1. So I uninstalled
> guile,
> downloaded the sources for guile 1.4.1, untarred them and
> ran
> ./configure --disable-shared
>
> It runs through several checks, but never completes - insted it
> gives me at some point it simply gives me the blue screen of death.
> This time around Im not even getting past configure.
>
> Im not sure what to do now.
> Any advice at all would be greatly appreciated.
>
> Much thanks
> Bhiksha
> bhiksha@merl.com
>
> P.S: Ive hunted on the web and faqs for answers and couldnt find
> any.

Bhiksha,

Just two notes: it is unlikely that anyone will answer your post right
away on a weekend, so repeating your posts is only going to annoy people.
Especially if your second post continues an unrelated thread - it's much
better to start a new one, so people with threaded browsers notice your
post.  Your second message does have a much more descriptive subject,
though.

For further info, see answers to your original post <http://cygwin.com/ml/cygwin/2003-01/msg00561.html>.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune

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

[Charles Wilson]

[-- Attachment #1: Type: text/plain, Size: 1691 bytes --]

Earnie Boyd wrote:
> Charles Wilson wrote:
> 
>>
>> 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.
>>
> 
> This can be resolved by ``. ./foo.'' instead for the cygwin/mingw hosts.

I knew that would work for cygwin, but wasn't sure it would work for 
mingw.  In that case, this portion of the earlier patch:

@@ -5066,8 +5261,12 @@

  	  # If there is no directory component, then add one.
  	  case $file in
-	  */* | *\\*) . $wrapper ;;
-	  *) . ./$wrapper ;;
+	  */* | *\\*) cp ${wrapper} ${wrapper}-lt.sh
+	    . ${wrapper}-lt.sh
+	    $rm -f ${wrapper}-lt.sh ;;
+	  *) cp ./${wrapper} ./${wrapper}-lt.sh
+	    . ./${wrapper}-lt.sh
+	    $rm -f ${wrapper}-lt.sh ;;
  	  esac

  	  # Check the variables that should have been set.
@@ -5097,8 +5296,12 @@
  	  relink_command=
  	  # If there is no directory component, then add one.
  	  case $file in
-	  */* | *\\*) . $file ;;
-	  *) . ./$file ;;
+	  */* | *\\*) cp ${wrapper} ${wrapper}-lt.sh
+	    . ${wrapper}-lt.sh
+	    $rm -f ${wrapper}-lt.sh ;;
+	  *) cp ./${wrapper} ./${wrapper}-lt.sh
+	    . ./${wrapper}-lt.sh
+	    $rm -f ${wrapper}-lt.sh ;;
  	  esac

  	  outputname=

could be replaced with the attached version, instead (note: attached 
file is NOT a complete patch, and hasn't been tested extensively.)  The 
newer version has the benefit that it avoids the race introduced by the 
above.  I'm not sure it is advisable to change the definition of 
$wrapper itself for cygwin/mingw host, though, so I introduced a new 
variable wrapperdot.

--
Chuck



[-- Attachment #2: libtool-relinkexe3partial.patch --]
[-- Type: text/plain, Size: 1145 bytes --]

@@ -5064,10 +5259,17 @@
 	  notinst_deplibs=
 	  relink_command=
 
+	  # To insure that "foo" is sourced, and not "foo.exe",
+	  # finese the cygwin/MSYS system by explicitly sourcing "foo."
+	  # which disallows the automatic-append-.exe behavior.
+	  case $host in
+	  *cygwin* | *mingw*) wrapperdot=${wrapper}.
+	  *) wrapperdot=${wrapper}
+	  esac
 	  # If there is no directory component, then add one.
 	  case $file in
-	  */* | *\\*) . $wrapper ;;
-	  *) . ./$wrapper ;;
+	  */* | *\\*) . ${wrapperdot}
+	  *) . ./${wrapperdot}
 	  esac
 
 	  # Check the variables that should have been set.
@@ -5095,10 +5297,17 @@
 	  done
 
 	  relink_command=
+	  # To insure that "foo" is sourced, and not "foo.exe",
+	  # finese the cygwin/MSYS system by explicitly sourcing "foo."
+	  # which disallows the automatic-append-.exe behavior.
+	  case $host in
+	  *cygwin* | *mingw*) wrapperdot=${wrapper}.
+	  *) wrapperdot=${wrapper}
+	  esac
 	  # If there is no directory component, then add one.
 	  case $file in
-	  */* | *\\*) . $file ;;
-	  *) . ./$file ;;
+	  */* | *\\*) . ${wrapperdot}
+	  *) . ./${wrapperdot}
 	  esac
 
 	  outputname=

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

[Charles Wilson]

Alexandre Duret-Lutz wrote:

> Any way lt-foo.c could go into .libs/?  Or just be erased after
> foo.exe has been built?  Maybe both?

I see no problems with either or both...but I'd rather keep lt-foo.c 
around until 'make clean' (or libtool --mode=clean) time.

> Also I if you don't move `foo' to `.libs/' I think you
> should ensure that `libtool --mode=clean rm -f foo.exe' 
> erases `foo'.  

Good point.  "libtool --mode=clean" won't currently get both of them. 
But automake's 'make clean' will (see below).

> (Or does Cygwin's `rm' erase both at once?)

No, it doesn't.

> Right now Automake doesn't use `--mode=clean'.  Maybe Automake
> 1.8 could start doing this so we don't have to hardcode this
> sort of knowledge.

Yeah, I think this has come up before...

However, current automake "make clean" will at least attempt to delete 
all four of the following, whether they exist or not:
   foo
   foo.exe
   .libs/foo     (*)
   .libs/foo.exe (*)
(*) by virtue of rm -rf'ing .libs

So, there's really no worry about cleaning up the shell wrapper or the 
"real" executable -- or the binary wrapper -- with present automake. 
But cleaning up the lt-foo.c file is an issue.  I'd prefer to move it 
into .libs, but NOT erase it; automake's make clean will "get it" if 
it's in .libs (see rm -rf, above)

'Course, transitioning to libtool --mode=clean will mess that up, unless 
the problems you mention are addressed...

--Chuck


--
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/

Re: Solving the "relink exe's" libtool problem [take 3]

[Charles Wilson]

[-- Attachment #1: Type: text/plain, Size: 584 bytes --]

Okay, this version

1) puts lt-foo.c into .libs

2) "libtool --mode=clean" does the right thing --- cleans up foo, 
foo.exe, .libs/foo.exe, .libs/lt-foo.c, plus whatever else it already 
took care of.

3) lt-foo.c actually passes its own arguments to the shell wrapper -- it 
didn't, before. (Oops)

libtool regression tests: no new failures (on cygwin)
briefly tested on another project; worked fine.

Binary packages for cygwin (libtool-devel-20030103-4, 
libltdl3-20030103-4) available by pointing setup.exe at 
http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/

--Chuck

[-- Attachment #2: libtool-relinkexe3.patch --]
[-- Type: text/plain, Size: 8003 bytes --]

Index: ltmain.in
===================================================================
RCS file: /cvsroot/libtool/libtool/ltmain.in,v
retrieving revision 1.318
diff -u -r1.318 ltmain.in
--- ltmain.in	1 Jan 2003 01:57:47 -0000	1.318
+++ ltmain.in	13 Jan 2003 04:48:39 -0000
@@ -4284,6 +4284,207 @@
 	    outputname=`echo $outputname|${SED} 's,.exe$,,'` ;;
 	  *) exeext= ;;
 	esac
+	case $host in
+	  *cygwin* | *mingw* )
+	    cwrappersource=`echo ${objdir}/lt-${output}.c`
+	    cwrapper=`echo ${output}.exe`
+	    $rm $cwrappersource $cwrapper
+	    trap "$rm $cwrappersource $cwrapper; exit 1" 1 2 15
+
+	    cat > $cwrappersource <<EOF
+
+/* $cwrappersource - temporary wrapper executable for $objdir/$outputname
+   Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP
+
+   The $output program cannot be directly executed until all the libtool
+   libraries that it depends on are installed.
+   
+   This wrapper executable should never be moved out of the build directory.
+   If it is, it will not operate correctly.
+
+   Currently, it simply execs the wrapper *script* "/bin/sh $output",
+   but could eventually absorb all of the scripts functionality and
+   exec $objdir/$outputname directly.
+*/
+EOF
+	    cat >> $cwrappersource<<"EOF"
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <malloc.h>
+#include <stdarg.h>
+#include <assert.h>
+
+#if defined(PATH_MAX)
+# define LT_PATHMAX PATH_MAX
+#elif defined(MAXPATHLEN)
+# define LT_PATHMAX MAXPATHLEN
+#else
+# define LT_PATHMAX 1024
+#endif
+
+#ifndef DIR_SEPARATOR
+#define DIR_SEPARATOR '/'
+#endif
+
+#if defined (_WIN32) || defined (__MSDOS__) || defined (__DJGPP__) || \
+  defined (__OS2__)
+#define HAVE_DOS_BASED_FILE_SYSTEM
+#ifndef DIR_SEPARATOR_2 
+#define DIR_SEPARATOR_2 '\\'
+#endif
+#endif
+
+#ifndef DIR_SEPARATOR_2
+# define IS_DIR_SEPARATOR(ch) ((ch) == DIR_SEPARATOR)
+#else /* DIR_SEPARATOR_2 */
+# define IS_DIR_SEPARATOR(ch) \
+        (((ch) == DIR_SEPARATOR) || ((ch) == DIR_SEPARATOR_2))
+#endif /* DIR_SEPARATOR_2 */
+
+#define XMALLOC(type, num)      ((type *) xmalloc ((num) * sizeof(type)))
+#define XFREE(stale) do { \
+  if (stale) { free ((void *) stale); stale = 0; } \
+} while (0)
+
+const char *program_name = NULL;
+
+void * xmalloc (size_t num);
+char * xstrdup (const char *string);
+char * basename (const char *name);
+char * fnqualify(const char *path);
+char * strendzap(char *str, const char *pat);
+void lt_fatal (const char *message, ...);
+
+int
+main (int argc, char *argv[])
+{
+  char **newargz;
+  int i;
+  
+  program_name = (char *) xstrdup ((char *) basename (argv[0]));
+  newargz = XMALLOC(char *, argc+2);
+  newargz[0] = xstrdup("/bin/sh");
+  newargz[1] = fnqualify(argv[0]);
+  /* we know the script has the same name, without the .exe */
+  /* so make sure newargz[1] doesn't end in .exe */
+  strendzap(newargz[1],".exe"); 
+  for (i = 1; i < argc; i++)
+    newargz[i+1] = xstrdup(argv[i]);
+  newargz[argc+1] = NULL;
+  execv("/bin/sh",newargz);
+}
+
+void *
+xmalloc (size_t num)
+{
+  void * p = (void *) malloc (num);
+  if (!p)
+    lt_fatal ("Memory exhausted");
+
+  return p;
+}
+
+char * 
+xstrdup (const char *string)
+{
+  return string ? strcpy ((char *) xmalloc (strlen (string) + 1), string) : NULL
+;
+}
+
+char *
+basename (const char *name)
+{
+  const char *base;
+
+#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
+  /* Skip over the disk name in MSDOS pathnames. */
+  if (isalpha (name[0]) && name[1] == ':') 
+    name += 2;
+#endif
+
+  for (base = name; *name; name++)
+    if (IS_DIR_SEPARATOR (*name))
+      base = name + 1;
+  return (char *) base;
+}
+
+char * 
+fnqualify(const char *path)
+{
+  size_t size;
+  char *p;
+  char tmp[LT_PATHMAX + 1];
+
+  assert(path != NULL);
+
+  /* Is it qualified already? */
+#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
+  if (isalpha (path[0]) && path[1] == ':')
+    return xstrdup (path);
+#endif
+  if (IS_DIR_SEPARATOR (path[0]))
+    return xstrdup (path);
+
+  /* prepend the current directory */
+  /* doesn't handle '~' */
+  if (getcwd (tmp, LT_PATHMAX) == NULL)
+    lt_fatal ("getcwd failed");
+  size = strlen(tmp) + 1 + strlen(path) + 1; /* +2 for '/' and '\0' */
+  p = XMALLOC(char, size);
+  sprintf(p, "%s%c%s", tmp, DIR_SEPARATOR, path);
+  return p;
+}
+
+char *
+strendzap(char *str, const char *pat) 
+{
+  size_t len, patlen;
+
+  assert(str != NULL);
+  assert(pat != NULL);
+
+  len = strlen(str);
+  patlen = strlen(pat);
+
+  if (patlen <= len)
+  {
+    str += len - patlen;
+    if (strcmp(str, pat) == 0)
+      *str = '\0';
+  }
+  return str;
+}
+
+static void
+lt_error_core (int exit_status, const char * mode, 
+          const char * message, va_list ap)
+{
+  fprintf (stderr, "%s: %s: ", program_name, mode);
+  vfprintf (stderr, message, ap);
+  fprintf (stderr, ".\n");
+
+  if (exit_status >= 0)
+    exit (exit_status);
+}
+
+void
+lt_fatal (const char *message, ...)
+{
+  va_list ap;
+  va_start (ap, message);
+  lt_error_core (EXIT_FAILURE, "FATAL", message, ap);
+  va_end (ap);
+}
+EOF
+	  # 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
+	  ;;
+	esac
 	$rm $output
 	trap "$rm $output; exit 1" 1 2 15
 
@@ -5064,10 +5265,17 @@
 	  notinst_deplibs=
 	  relink_command=
 
+	  # To insure that "foo" is sourced, and not "foo.exe",
+	  # finese the cygwin/MSYS system by explicitly sourcing "foo."
+	  # which disallows the automatic-append-.exe behavior.
+	  case $host in
+	  *cygwin* | *mingw*) wrapperdot=${wrapper}. ;;
+	  *) wrapperdot=${wrapper} ;;
+	  esac
 	  # If there is no directory component, then add one.
 	  case $file in
-	  */* | *\\*) . $wrapper ;;
-	  *) . ./$wrapper ;;
+	  */* | *\\*) . ${wrapperdot} ;;
+	  *) . ./${wrapperdot} ;;
 	  esac
 
 	  # Check the variables that should have been set.
@@ -5095,10 +5303,17 @@
 	  done
 
 	  relink_command=
+	  # To insure that "foo" is sourced, and not "foo.exe",
+	  # finese the cygwin/MSYS system by explicitly sourcing "foo."
+	  # which disallows the automatic-append-.exe behavior.
+	  case $host in
+	  *cygwin* | *mingw*) wrapperdot=${wrapper}. ;;
+	  *) wrapperdot=${wrapper} ;;
+	  esac
 	  # If there is no directory component, then add one.
 	  case $file in
-	  */* | *\\*) . $file ;;
-	  *) . ./$file ;;
+	  */* | *\\*) . ${wrapperdot} ;;
+	  *) . ./${wrapperdot} ;;
 	  esac
 
 	  outputname=
@@ -5541,15 +5756,31 @@
 	;;
 
       *)
-	# Do a test to see if this is a libtool program.
-	if test "$mode" = clean &&
-	   (${SED} -e '4q' $file | grep "^# Generated by .*$PACKAGE") >/dev/null 2>&1; then
-	  relink_command=
-	  . $dir/$file
-
-	  rmfiles="$rmfiles $objdir/$name $objdir/${name}S.${objext}"
-	  if test "$fast_install" = yes && test -n "$relink_command"; then
-	    rmfiles="$rmfiles $objdir/lt-$name"
+	if test "$mode" = clean ; then
+	  noexename=$name
+	  case $file in
+	  *.exe) 
+	    file=`echo $file|${SED} 's,.exe$,,'`
+	    noexename=`echo $name|${SED} 's,.exe$,,'`
+	    # $file with .exe has already been added to rmfiles,
+	    # add $file without .exe
+	    rmfiles="$rmfiles $file"
+	    ;;
+	  esac
+	  # Do a test to see if this is a libtool program.
+	  if (${SED} -e '4q' $file | grep "^# Generated by .*$PACKAGE") >/dev/null 2>&1; then
+	    relink_command=
+	    . $dir/$file
+
+	    # note $name still contains .exe if it was in $file originally
+	    # as does the version of $file that was added into $rmfiles
+	    rmfiles="$rmfiles $objdir/$name $objdir/${name}S.${objext}"
+	    if test "$fast_install" = yes && test -n "$relink_command"; then
+	      rmfiles="$rmfiles $objdir/lt-$name"
+	    fi
+	    if test "X$noexename" != "X$name" ; then
+	      rmfiles="$rmfiles $objdir/lt-${noexename}.c"
+	    fi
 	  fi
 	fi
 	;;

[-- Attachment #3: libtool-relinkexe3.changelog --]
[-- Type: text/plain, Size: 349 bytes --]

2003-01-12  Charles Wilson  <cwilson@ece.gatech.edu>

	* ltmain.in: add code for a binary wrapper
	to use with uninstalled executables on cygwin/mingw.
	Make sure that --mode=clean gets shell wrapper and
	binary wrapper.  When sourcing the shell wrapper, 
	invoke using a terminal `.' on cygwin/mingw to 
	avoid the automatic append-.exe behavior.


[-- Attachment #4: Type: text/plain, Size: 214 bytes --]

--
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/

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

[Earnie Boyd]

This patch passes my test.  What do we need to do to get this accepted 
into libtool cvs HEAD?

Earnie.

Charles Wilson wrote:
> Okay, this version
> 
> 1) puts lt-foo.c into .libs
> 
> 2) "libtool --mode=clean" does the right thing --- cleans up foo, 
> foo.exe, .libs/foo.exe, .libs/lt-foo.c, plus whatever else it already 
> took care of.
> 
> 3) lt-foo.c actually passes its own arguments to the shell wrapper -- it 
> didn't, before. (Oops)
> 
> libtool regression tests: no new failures (on cygwin)
> briefly tested on another project; worked fine.
> 
> Binary packages for cygwin (libtool-devel-20030103-4, 
> libltdl3-20030103-4) available by pointing setup.exe at 
> http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/
> 
> --Chuck
> 
> 
> ------------------------------------------------------------------------
> 
> Index: ltmain.in
> ===================================================================
> RCS file: /cvsroot/libtool/libtool/ltmain.in,v
> retrieving revision 1.318
> diff -u -r1.318 ltmain.in
> --- ltmain.in	1 Jan 2003 01:57:47 -0000	1.318
> +++ ltmain.in	13 Jan 2003 04:48:39 -0000
> @@ -4284,6 +4284,207 @@
>  	    outputname=`echo $outputname|${SED} 's,.exe$,,'` ;;
>  	  *) exeext= ;;
>  	esac
> +	case $host in
> +	  *cygwin* | *mingw* )
> +	    cwrappersource=`echo ${objdir}/lt-${output}.c`
> +	    cwrapper=`echo ${output}.exe`
> +	    $rm $cwrappersource $cwrapper
> +	    trap "$rm $cwrappersource $cwrapper; exit 1" 1 2 15
> +
> +	    cat > $cwrappersource <<EOF
> +
> +/* $cwrappersource - temporary wrapper executable for $objdir/$outputname
> +   Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP
> +
> +   The $output program cannot be directly executed until all the libtool
> +   libraries that it depends on are installed.
> +   
> +   This wrapper executable should never be moved out of the build directory.
> +   If it is, it will not operate correctly.
> +
> +   Currently, it simply execs the wrapper *script* "/bin/sh $output",
> +   but could eventually absorb all of the scripts functionality and
> +   exec $objdir/$outputname directly.
> +*/
> +EOF
> +	    cat >> $cwrappersource<<"EOF"
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <unistd.h>
> +#include <malloc.h>
> +#include <stdarg.h>
> +#include <assert.h>
> +
> +#if defined(PATH_MAX)
> +# define LT_PATHMAX PATH_MAX
> +#elif defined(MAXPATHLEN)
> +# define LT_PATHMAX MAXPATHLEN
> +#else
> +# define LT_PATHMAX 1024
> +#endif
> +
> +#ifndef DIR_SEPARATOR
> +#define DIR_SEPARATOR '/'
> +#endif
> +
> +#if defined (_WIN32) || defined (__MSDOS__) || defined (__DJGPP__) || \
> +  defined (__OS2__)
> +#define HAVE_DOS_BASED_FILE_SYSTEM
> +#ifndef DIR_SEPARATOR_2 
> +#define DIR_SEPARATOR_2 '\\'
> +#endif
> +#endif
> +
> +#ifndef DIR_SEPARATOR_2
> +# define IS_DIR_SEPARATOR(ch) ((ch) == DIR_SEPARATOR)
> +#else /* DIR_SEPARATOR_2 */
> +# define IS_DIR_SEPARATOR(ch) \
> +        (((ch) == DIR_SEPARATOR) || ((ch) == DIR_SEPARATOR_2))
> +#endif /* DIR_SEPARATOR_2 */
> +
> +#define XMALLOC(type, num)      ((type *) xmalloc ((num) * sizeof(type)))
> +#define XFREE(stale) do { \
> +  if (stale) { free ((void *) stale); stale = 0; } \
> +} while (0)
> +
> +const char *program_name = NULL;
> +
> +void * xmalloc (size_t num);
> +char * xstrdup (const char *string);
> +char * basename (const char *name);
> +char * fnqualify(const char *path);
> +char * strendzap(char *str, const char *pat);
> +void lt_fatal (const char *message, ...);
> +
> +int
> +main (int argc, char *argv[])
> +{
> +  char **newargz;
> +  int i;
> +  
> +  program_name = (char *) xstrdup ((char *) basename (argv[0]));
> +  newargz = XMALLOC(char *, argc+2);
> +  newargz[0] = xstrdup("/bin/sh");
> +  newargz[1] = fnqualify(argv[0]);
> +  /* we know the script has the same name, without the .exe */
> +  /* so make sure newargz[1] doesn't end in .exe */
> +  strendzap(newargz[1],".exe"); 
> +  for (i = 1; i < argc; i++)
> +    newargz[i+1] = xstrdup(argv[i]);
> +  newargz[argc+1] = NULL;
> +  execv("/bin/sh",newargz);
> +}
> +
> +void *
> +xmalloc (size_t num)
> +{
> +  void * p = (void *) malloc (num);
> +  if (!p)
> +    lt_fatal ("Memory exhausted");
> +
> +  return p;
> +}
> +
> +char * 
> +xstrdup (const char *string)
> +{
> +  return string ? strcpy ((char *) xmalloc (strlen (string) + 1), string) : NULL
> +;
> +}
> +
> +char *
> +basename (const char *name)
> +{
> +  const char *base;
> +
> +#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
> +  /* Skip over the disk name in MSDOS pathnames. */
> +  if (isalpha (name[0]) && name[1] == ':') 
> +    name += 2;
> +#endif
> +
> +  for (base = name; *name; name++)
> +    if (IS_DIR_SEPARATOR (*name))
> +      base = name + 1;
> +  return (char *) base;
> +}
> +
> +char * 
> +fnqualify(const char *path)
> +{
> +  size_t size;
> +  char *p;
> +  char tmp[LT_PATHMAX + 1];
> +
> +  assert(path != NULL);
> +
> +  /* Is it qualified already? */
> +#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
> +  if (isalpha (path[0]) && path[1] == ':')
> +    return xstrdup (path);
> +#endif
> +  if (IS_DIR_SEPARATOR (path[0]))
> +    return xstrdup (path);
> +
> +  /* prepend the current directory */
> +  /* doesn't handle '~' */
> +  if (getcwd (tmp, LT_PATHMAX) == NULL)
> +    lt_fatal ("getcwd failed");
> +  size = strlen(tmp) + 1 + strlen(path) + 1; /* +2 for '/' and '\0' */
> +  p = XMALLOC(char, size);
> +  sprintf(p, "%s%c%s", tmp, DIR_SEPARATOR, path);
> +  return p;
> +}
> +
> +char *
> +strendzap(char *str, const char *pat) 
> +{
> +  size_t len, patlen;
> +
> +  assert(str != NULL);
> +  assert(pat != NULL);
> +
> +  len = strlen(str);
> +  patlen = strlen(pat);
> +
> +  if (patlen <= len)
> +  {
> +    str += len - patlen;
> +    if (strcmp(str, pat) == 0)
> +      *str = '\0';
> +  }
> +  return str;
> +}
> +
> +static void
> +lt_error_core (int exit_status, const char * mode, 
> +          const char * message, va_list ap)
> +{
> +  fprintf (stderr, "%s: %s: ", program_name, mode);
> +  vfprintf (stderr, message, ap);
> +  fprintf (stderr, ".\n");
> +
> +  if (exit_status >= 0)
> +    exit (exit_status);
> +}
> +
> +void
> +lt_fatal (const char *message, ...)
> +{
> +  va_list ap;
> +  va_start (ap, message);
> +  lt_error_core (EXIT_FAILURE, "FATAL", message, ap);
> +  va_end (ap);
> +}
> +EOF
> +	  # 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
> +	  ;;
> +	esac
>  	$rm $output
>  	trap "$rm $output; exit 1" 1 2 15
>  
> @@ -5064,10 +5265,17 @@
>  	  notinst_deplibs=
>  	  relink_command=
>  
> +	  # To insure that "foo" is sourced, and not "foo.exe",
> +	  # finese the cygwin/MSYS system by explicitly sourcing "foo."
> +	  # which disallows the automatic-append-.exe behavior.
> +	  case $host in
> +	  *cygwin* | *mingw*) wrapperdot=${wrapper}. ;;
> +	  *) wrapperdot=${wrapper} ;;
> +	  esac
>  	  # If there is no directory component, then add one.
>  	  case $file in
> -	  */* | *\\*) . $wrapper ;;
> -	  *) . ./$wrapper ;;
> +	  */* | *\\*) . ${wrapperdot} ;;
> +	  *) . ./${wrapperdot} ;;
>  	  esac
>  
>  	  # Check the variables that should have been set.
> @@ -5095,10 +5303,17 @@
>  	  done
>  
>  	  relink_command=
> +	  # To insure that "foo" is sourced, and not "foo.exe",
> +	  # finese the cygwin/MSYS system by explicitly sourcing "foo."
> +	  # which disallows the automatic-append-.exe behavior.
> +	  case $host in
> +	  *cygwin* | *mingw*) wrapperdot=${wrapper}. ;;
> +	  *) wrapperdot=${wrapper} ;;
> +	  esac
>  	  # If there is no directory component, then add one.
>  	  case $file in
> -	  */* | *\\*) . $file ;;
> -	  *) . ./$file ;;
> +	  */* | *\\*) . ${wrapperdot} ;;
> +	  *) . ./${wrapperdot} ;;
>  	  esac
>  
>  	  outputname=
> @@ -5541,15 +5756,31 @@
>  	;;
>  
>        *)
> -	# Do a test to see if this is a libtool program.
> -	if test "$mode" = clean &&
> -	   (${SED} -e '4q' $file | grep "^# Generated by .*$PACKAGE") >/dev/null 2>&1; then
> -	  relink_command=
> -	  . $dir/$file
> -
> -	  rmfiles="$rmfiles $objdir/$name $objdir/${name}S.${objext}"
> -	  if test "$fast_install" = yes && test -n "$relink_command"; then
> -	    rmfiles="$rmfiles $objdir/lt-$name"
> +	if test "$mode" = clean ; then
> +	  noexename=$name
> +	  case $file in
> +	  *.exe) 
> +	    file=`echo $file|${SED} 's,.exe$,,'`
> +	    noexename=`echo $name|${SED} 's,.exe$,,'`
> +	    # $file with .exe has already been added to rmfiles,
> +	    # add $file without .exe
> +	    rmfiles="$rmfiles $file"
> +	    ;;
> +	  esac
> +	  # Do a test to see if this is a libtool program.
> +	  if (${SED} -e '4q' $file | grep "^# Generated by .*$PACKAGE") >/dev/null 2>&1; then
> +	    relink_command=
> +	    . $dir/$file
> +
> +	    # note $name still contains .exe if it was in $file originally
> +	    # as does the version of $file that was added into $rmfiles
> +	    rmfiles="$rmfiles $objdir/$name $objdir/${name}S.${objext}"
> +	    if test "$fast_install" = yes && test -n "$relink_command"; then
> +	      rmfiles="$rmfiles $objdir/lt-$name"
> +	    fi
> +	    if test "X$noexename" != "X$name" ; then
> +	      rmfiles="$rmfiles $objdir/lt-${noexename}.c"
> +	    fi
>  	  fi
>  	fi
>  	;;
> 
> 
> ------------------------------------------------------------------------
> 
> 2003-01-12  Charles Wilson  <cwilson@ece.gatech.edu>
> 
> 	* ltmain.in: add code for a binary wrapper
> 	to use with uninstalled executables on cygwin/mingw.
> 	Make sure that --mode=clean gets shell wrapper and
> 	binary wrapper.  When sourcing the shell wrapper, 
> 	invoke using a terminal `.' on cygwin/mingw to 
> 	avoid the automatic append-.exe behavior.


--
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/

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

[Bruce Korb]

Earnie Boyd wrote:
> 
> This patch passes my test.  What do we need to do to get this accepted
> into libtool cvs HEAD?

> > +  newargz[0] = xstrdup("/bin/sh");

This may not be the shell and there is no point allocating it.
It is fine to use it from static memory.

--
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/

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

[Charles Wilson]

Bruce Korb wrote:
> Earnie Boyd wrote:
> 
>>This patch passes my test.  What do we need to do to get this accepted
>>into libtool cvs HEAD?
> 
> 
>>>+  newargz[0] = xstrdup("/bin/sh");
>>
> 
> This may not be the shell and there is no point allocating it.
> It is fine to use it from static memory.

Okay, the second comment (use static string, not allocated memory) is 
easy enough.  But what's the best way to use "the shell"?  Do a unquoted 
replacement (<<EOF, not <<"EOF") e.g.

   ...
   newargz = XMALLOC(char *, argc+2);
EOF
$echo >> $cwrappersource <<EOF
   newargz[0] = \"$SHELL\";
EOF
$echo >> $cwrappersource <<"EOF"
   newargz[1] = fnqualify(argv[0]);
   ...

?

--Chuck



--
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/

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

[Bruce Korb]

Charles Wilson wrote:
> 
> Bruce Korb wrote:
> > Earnie Boyd wrote:
> >
> >>This patch passes my test.  What do we need to do to get this accepted
> >>into libtool cvs HEAD?
> >
> >
> >>>+  newargz[0] = xstrdup("/bin/sh");
> >>
> >
> > This may not be the shell and there is no point allocating it.
> > It is fine to use it from static memory.
> 
> Okay, the second comment (use static string, not allocated memory) is
I wouldn't have mentioned the static string by itself ;-)

> easy enough.  But what's the best way to use "the shell"?  Do a unquoted
> replacement (<<EOF, not <<"EOF") e.g.
Yes.

Somewhere, buried in the configury stuff is an environment
variable named something like, "CONFIG_SHELL".  That's what
you want.  If it is not available, then imitating the techniques
used to obtain it by configure should be used.

--
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/

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

[Charles Wilson]

>>easy enough.  But what's the best way to use "the shell"?  Do a unquoted
>>replacement (<<EOF, not <<"EOF") e.g.
> 
> Yes.
> 
> Somewhere, buried in the configury stuff is an environment
> variable named something like, "CONFIG_SHELL".  That's what
> you want.  If it is not available, then imitating the techniques
> used to obtain it by configure should be used.

But lt-foo.c is created by the libtool script itself -- and libtool 
already knows that $SHELL == /bin/sh or /bin/bash or whatever.  libtool 
uses the same method I described when creating the shell wrapper:

         $echo > $output "\
#! $SHELL
# $output - temporary wrapper script for $objdir/$outputname
...

So I really don't need to worry about $CONFIG_SHELL or imitating 
configure, do I?  I can just use $SHELL.

--Chuck


--
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/

Re: Solving the "relink exe's" libtool problem[take4]

[Charles Wilson]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

[dropped automake-patches from the CC: list; this discuession has long 
since ceased involving automake]

This version addresses the two issues raised by Bruce: using the shell 
that is appropriate for the platform, as determined during configure 
(since that is how the libtool variable $SHELL is assigned), and using a 
static string constant instead of dynamically allocating storage -- 
since we know before compile time what the value of the string will be 
(/bin/sh or /bin/bash or whatever).

I really feel like we're in nitpick mode here.  If there are no 
*substantive* objections, can we check THIS version in?  And then clean 
up the additional nitpicks, if any, as additional patches?

The only difference between this patch and the previous one is in the 
main() function, and the patch as a whole has been regenerated against 
current CVS.

--Chuck



[-- Attachment #2: libtool-relinkexe4.changelog --]
[-- Type: text/plain, Size: 348 bytes --]

2003-01-21  Charles Wilson  <cwilson@ece.gatech.edu>

	* ltmain.in: add code for a binary wrapper
	to use with uninstalled executables on cygwin/mingw.
	Make sure that --mode=clean gets shell wrapper and
	binary wrapper.  When sourcing the shell wrapper, 
	invoke using a terminal `.' on cygwin/mingw to 
	avoid the automatic append-.exe behavior.

[-- Attachment #3: libtool-relinkexe4.patch --]
[-- Type: text/plain, Size: 8169 bytes --]

Index: ltmain.in
===================================================================
RCS file: /cvsroot/libtool/libtool/ltmain.in,v
retrieving revision 1.320
diff -u -u -r1.320 ltmain.in
--- ltmain.in	15 Jan 2003 02:55:34 -0000	1.320
+++ ltmain.in	21 Jan 2003 04:01:39 -0000
@@ -4291,6 +4291,219 @@
 	    outputname=`echo $outputname|${SED} 's,.exe$,,'` ;;
 	  *) exeext= ;;
 	esac
+	case $host in
+	  *cygwin* | *mingw* )
+	    cwrappersource=`echo ${objdir}/lt-${output}.c`
+	    cwrapper=`echo ${output}.exe`
+	    $rm $cwrappersource $cwrapper
+	    trap "$rm $cwrappersource $cwrapper; exit 1" 1 2 15
+
+	    cat > $cwrappersource <<EOF
+
+/* $cwrappersource - temporary wrapper executable for $objdir/$outputname
+   Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP
+
+   The $output program cannot be directly executed until all the libtool
+   libraries that it depends on are installed.
+   
+   This wrapper executable should never be moved out of the build directory.
+   If it is, it will not operate correctly.
+
+   Currently, it simply execs the wrapper *script* "/bin/sh $output",
+   but could eventually absorb all of the scripts functionality and
+   exec $objdir/$outputname directly.
+*/
+EOF
+	    cat >> $cwrappersource<<"EOF"
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <malloc.h>
+#include <stdarg.h>
+#include <assert.h>
+
+#if defined(PATH_MAX)
+# define LT_PATHMAX PATH_MAX
+#elif defined(MAXPATHLEN)
+# define LT_PATHMAX MAXPATHLEN
+#else
+# define LT_PATHMAX 1024
+#endif
+
+#ifndef DIR_SEPARATOR
+#define DIR_SEPARATOR '/'
+#endif
+
+#if defined (_WIN32) || defined (__MSDOS__) || defined (__DJGPP__) || \
+  defined (__OS2__)
+#define HAVE_DOS_BASED_FILE_SYSTEM
+#ifndef DIR_SEPARATOR_2 
+#define DIR_SEPARATOR_2 '\\'
+#endif
+#endif
+
+#ifndef DIR_SEPARATOR_2
+# define IS_DIR_SEPARATOR(ch) ((ch) == DIR_SEPARATOR)
+#else /* DIR_SEPARATOR_2 */
+# define IS_DIR_SEPARATOR(ch) \
+        (((ch) == DIR_SEPARATOR) || ((ch) == DIR_SEPARATOR_2))
+#endif /* DIR_SEPARATOR_2 */
+
+#define XMALLOC(type, num)      ((type *) xmalloc ((num) * sizeof(type)))
+#define XFREE(stale) do { \
+  if (stale) { free ((void *) stale); stale = 0; } \
+} while (0)
+
+const char *program_name = NULL;
+
+void * xmalloc (size_t num);
+char * xstrdup (const char *string);
+char * basename (const char *name);
+char * fnqualify(const char *path);
+char * strendzap(char *str, const char *pat);
+void lt_fatal (const char *message, ...);
+
+int
+main (int argc, char *argv[])
+{
+  char **newargz;
+  int i;
+  
+  program_name = (char *) xstrdup ((char *) basename (argv[0]));
+  newargz = XMALLOC(char *, argc+2);
+EOF
+
+	    cat >> $cwrappersource <<EOF
+  newargz[0] = "$SHELL";
+EOF
+
+	    cat >> $cwrappersource <<"EOF"
+  newargz[1] = fnqualify(argv[0]);
+  /* we know the script has the same name, without the .exe */
+  /* so make sure newargz[1] doesn't end in .exe */
+  strendzap(newargz[1],".exe"); 
+  for (i = 1; i < argc; i++)
+    newargz[i+1] = xstrdup(argv[i]);
+  newargz[argc+1] = NULL;
+EOF
+
+	    cat >> $cwrappersource <<EOF
+  execv("$SHELL",newargz);
+EOF
+
+	    cat >> $cwrappersource <<"EOF"
+}
+
+void *
+xmalloc (size_t num)
+{
+  void * p = (void *) malloc (num);
+  if (!p)
+    lt_fatal ("Memory exhausted");
+
+  return p;
+}
+
+char * 
+xstrdup (const char *string)
+{
+  return string ? strcpy ((char *) xmalloc (strlen (string) + 1), string) : NULL
+;
+}
+
+char *
+basename (const char *name)
+{
+  const char *base;
+
+#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
+  /* Skip over the disk name in MSDOS pathnames. */
+  if (isalpha (name[0]) && name[1] == ':') 
+    name += 2;
+#endif
+
+  for (base = name; *name; name++)
+    if (IS_DIR_SEPARATOR (*name))
+      base = name + 1;
+  return (char *) base;
+}
+
+char * 
+fnqualify(const char *path)
+{
+  size_t size;
+  char *p;
+  char tmp[LT_PATHMAX + 1];
+
+  assert(path != NULL);
+
+  /* Is it qualified already? */
+#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
+  if (isalpha (path[0]) && path[1] == ':')
+    return xstrdup (path);
+#endif
+  if (IS_DIR_SEPARATOR (path[0]))
+    return xstrdup (path);
+
+  /* prepend the current directory */
+  /* doesn't handle '~' */
+  if (getcwd (tmp, LT_PATHMAX) == NULL)
+    lt_fatal ("getcwd failed");
+  size = strlen(tmp) + 1 + strlen(path) + 1; /* +2 for '/' and '\0' */
+  p = XMALLOC(char, size);
+  sprintf(p, "%s%c%s", tmp, DIR_SEPARATOR, path);
+  return p;
+}
+
+char *
+strendzap(char *str, const char *pat) 
+{
+  size_t len, patlen;
+
+  assert(str != NULL);
+  assert(pat != NULL);
+
+  len = strlen(str);
+  patlen = strlen(pat);
+
+  if (patlen <= len)
+  {
+    str += len - patlen;
+    if (strcmp(str, pat) == 0)
+      *str = '\0';
+  }
+  return str;
+}
+
+static void
+lt_error_core (int exit_status, const char * mode, 
+          const char * message, va_list ap)
+{
+  fprintf (stderr, "%s: %s: ", program_name, mode);
+  vfprintf (stderr, message, ap);
+  fprintf (stderr, ".\n");
+
+  if (exit_status >= 0)
+    exit (exit_status);
+}
+
+void
+lt_fatal (const char *message, ...)
+{
+  va_list ap;
+  va_start (ap, message);
+  lt_error_core (EXIT_FAILURE, "FATAL", message, ap);
+  va_end (ap);
+}
+EOF
+	  # 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
+	  ;;
+	esac
 	$rm $output
 	trap "$rm $output; exit 1" 1 2 15
 
@@ -5071,10 +5284,17 @@
 	  notinst_deplibs=
 	  relink_command=
 
+	  # To insure that "foo" is sourced, and not "foo.exe",
+	  # finese the cygwin/MSYS system by explicitly sourcing "foo."
+	  # which disallows the automatic-append-.exe behavior.
+	  case $host in
+	  *cygwin* | *mingw*) wrapperdot=${wrapper}. ;;
+	  *) wrapperdot=${wrapper} ;;
+	  esac
 	  # If there is no directory component, then add one.
 	  case $file in
-	  */* | *\\*) . $wrapper ;;
-	  *) . ./$wrapper ;;
+	  */* | *\\*) . ${wrapperdot} ;;
+	  *) . ./${wrapperdot} ;;
 	  esac
 
 	  # Check the variables that should have been set.
@@ -5102,10 +5322,17 @@
 	  done
 
 	  relink_command=
+	  # To insure that "foo" is sourced, and not "foo.exe",
+	  # finese the cygwin/MSYS system by explicitly sourcing "foo."
+	  # which disallows the automatic-append-.exe behavior.
+	  case $host in
+	  *cygwin* | *mingw*) wrapperdot=${wrapper}. ;;
+	  *) wrapperdot=${wrapper} ;;
+	  esac
 	  # If there is no directory component, then add one.
 	  case $file in
-	  */* | *\\*) . $file ;;
-	  *) . ./$file ;;
+	  */* | *\\*) . ${wrapperdot} ;;
+	  *) . ./${wrapperdot} ;;
 	  esac
 
 	  outputname=
@@ -5548,15 +5775,31 @@
 	;;
 
       *)
-	# Do a test to see if this is a libtool program.
-	if test "$mode" = clean &&
-	   (${SED} -e '4q' $file | grep "^# Generated by .*$PACKAGE") >/dev/null 2>&1; then
-	  relink_command=
-	  . $dir/$file
-
-	  rmfiles="$rmfiles $objdir/$name $objdir/${name}S.${objext}"
-	  if test "$fast_install" = yes && test -n "$relink_command"; then
-	    rmfiles="$rmfiles $objdir/lt-$name"
+	if test "$mode" = clean ; then
+	  noexename=$name
+	  case $file in
+	  *.exe) 
+	    file=`echo $file|${SED} 's,.exe$,,'`
+	    noexename=`echo $name|${SED} 's,.exe$,,'`
+	    # $file with .exe has already been added to rmfiles,
+	    # add $file without .exe
+	    rmfiles="$rmfiles $file"
+	    ;;
+	  esac
+	  # Do a test to see if this is a libtool program.
+	  if (${SED} -e '4q' $file | grep "^# Generated by .*$PACKAGE") >/dev/null 2>&1; then
+	    relink_command=
+	    . $dir/$file
+
+	    # note $name still contains .exe if it was in $file originally
+	    # as does the version of $file that was added into $rmfiles
+	    rmfiles="$rmfiles $objdir/$name $objdir/${name}S.${objext}"
+	    if test "$fast_install" = yes && test -n "$relink_command"; then
+	      rmfiles="$rmfiles $objdir/lt-$name"
+	    fi
+	    if test "X$noexename" != "X$name" ; then
+	      rmfiles="$rmfiles $objdir/lt-${noexename}.c"
+	    fi
 	  fi
 	fi
 	;;


[-- Attachment #4: Type: text/plain, Size: 214 bytes --]

--
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/

Re: Solving the "relink exe's" libtool problem[take4]

[Boehne, Robert]

Charles,

Since I haven't heard any complaints about this patch, I'll
assume the Cygwin people are OK with it, and check it in.

Thanks,

Robert


-- 
Robert Boehne             Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  rboehne AT ricardo-us DOT com

--
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/

Re: Solving the "relink exe's" libtool problem[take4]

[Charles Wilson]

Boehne, Robert wrote:
> Charles,
> 
> Since I haven't heard any complaints about this patch, I'll
> assume the Cygwin people are OK with it, and check it in.

Thanks.  Looks good here (cygwin), causes no problems on non-windows 
(linux), and Earnie is happy with it on mingw.  So go for it.

--Chuck



--
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/