From: Charles W. <cw...@ec...> - 2003-01-06 18:11:57
|
[cross posted. Please keep (at least) cy...@cy... 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 |
From: Michael B. <mic...@gm...> - 2003-01-06 20:45:49
|
Charles Wilson wrote: > [cross posted. Please keep (at least) cy...@cy... 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 <cw...@ec...> > > * 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 <cw...@ec...> > > * 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. |
From: Alexandre Duret-L. <du...@lr...> - 2003-01-09 16:11:49
|
>>> "Chuck" == Charles Wilson <cw...@ec...> writes: Chuck> There has been a long-standing problem with libtool on windows-ish Chuck> platforms (cygwin, mingw, others?), in which libtool relinks exe's Chuck> over and over and over, when the exe depends on a shared lib that is Chuck> also built as part of the same package. Chuck> This behavior is due to the necessity that we must use a wrapper Chuck> script to set the PATH properly, so that the newly compiled exe can Chuck> "find" its shared lib, when run "in place" -- e.g. as part of a Chuck> test-suite. Thus, we have Chuck> <build-dir>/foo (wrapper script) Chuck> <build-dir>/.libs/foo.exe (real exe) Chuck> However, the Makefile target is "foo$(EXEEXT)" -- which Chuck> isn't satisfied by the "foo" wrapper script, so 'make' Chuck> keeps trying to create it. Maybe I'm wrong, but my understanding is that wrapper scripts are generated only when linking programs with uninstalled shared libraries. For instance wrapper scripts aren't created when the user uses --disable-shared, or simply if some program in the package doesn't link with shared libraries. In these cases reseting EXEEXT globally doesn't look like a solution (I guess it would just create the converse issue: the `foo:' target not satisfied by `foo.exe'). In the current situation I don't think there is any way to find out whether a Makefile target needs `.exe' appended. Chuck> However, the wrapper script can NOT be named "foo.exe", Chuck> for a number of good reasons. I assume these reasons are related to the word `script'? Have binaries been considered? [...] -- Alexandre Duret-Lutz |
From: Charles W. <cw...@ec...> - 2003-01-09 20:53:58
|
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 |
From: Earnie B. <ear...@ya...> - 2003-01-09 21:45:10
|
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. |
From: Alexandre Duret-L. <du...@lr...> - 2003-01-09 22:02:36
|
>>> "Chuck" == Charles Wilson <cw...@ec...> 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 |
From: Charles W. <cw...@ec...> - 2003-01-12 01:08:59
Attachments:
libtool-relinkexe2.changelog
libtool-relinkexe2.patch
|
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 |
From: Earnie B. <ear...@ya...> - 2003-01-12 14:06:54
|
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. |
From: Charles W. <cw...@ec...> - 2003-01-12 17:15:08
Attachments:
libtool-relinkexe3partial.patch
|
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 |
From: Alexandre Duret-L. <du...@lr...> - 2003-01-12 23:21:36
|
>>> "Chuck" == Charles Wilson <cw...@ec...> 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 |
From: Charles W. <cw...@ec...> - 2003-01-13 04:48:22
|
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 |
From: Charles W. <cw...@ec...> - 2003-01-13 07:58:17
Attachments:
libtool-relinkexe3.patch
libtool-relinkexe3.changelog
|
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 |
From: Earnie B. <ear...@ya...> - 2003-01-20 18:48:28
|
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 <cw...@ec...> > > * 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. |
From: Bruce K. <bk...@gn...> - 2003-01-20 19:31:46
|
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. |
From: Charles W. <cw...@ec...> - 2003-01-20 22:47:35
|
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 |
From: Bruce K. <bk...@ve...> - 2003-01-20 23:03:21
|
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. |
From: Charles W. <cw...@ec...> - 2003-01-21 01:40:36
|
>>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 |
From: Charles W. <cw...@ec...> - 2003-01-21 04:35:29
Attachments:
libtool-relinkexe4.changelog
libtool-relinkexe4.patch
|
[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 |
From: Boehne, R. <rob...@ri...> - 2003-01-28 22:37:04
|
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 |
From: Charles W. <cw...@ec...> - 2003-01-28 23:52:50
|
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 |