Re: [patch] 1.5.26 do echo=echo if necessary
Thien-Thi Nguyen wrote: > () Thien-Thi Nguyen <[EMAIL PROTECTED]> > () Sat, 08 Mar 2008 18:35:03 +0100 > >--- libtool-1.5.26/ltmain.sh.ORIG >+++ libtool-1.5.26/ltmain.sh > > I see now that ltmain.sh is produced from ltmain.in. > The change should be made there, instead. > > By the way, with this small change (and after installing > Libtool 1.5.26), Automake 1.10.1 "make check" is successful. Hi, It seems likely that you have a configure that was created with a different version of libtool than ltmain.sh was created with. For matching versions of libtool.m4 and ltmain.sh from libtool-1.5.26, the generated libtool script should already have: # An echo program that does not interpret backslashes. echo="echo" Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [patch] 1.5.26 do echo=echo if necessary
() Thien-Thi Nguyen <[EMAIL PROTECTED]> () Sat, 08 Mar 2008 18:35:03 +0100 --- libtool-1.5.26/ltmain.sh.ORIG +++ libtool-1.5.26/ltmain.sh I see now that ltmain.sh is produced from ltmain.in. The change should be made there, instead. By the way, with this small change (and after installing Libtool 1.5.26), Automake 1.10.1 "make check" is successful. thi ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: cross compilation to w32
Ralf Wildenhues wrote:
Does anybody see easy ways out?
Well, for the second problem there are two solutions. (1) always ensure
that the script is emitted with unix line endings, or (2) specify
$TARGETSHELL=/emulation/environment/sh when cross-compiling.
Obviously, (2) is the easiest, because getting rid of the requirement
for an emulator is going to take a bit more work. (1) is slightly more
difficult, and doesn't solve the emulator problem -- but at least
doesn't compound the problem.
For cygwin/msys, (1) means for --lt-dump-script, using setmode() on
stdout here:
if (strcmp (argv[i], dumpscript_opt) == 0)
{
<<< setmode here? >>>
printf ("%s", script_text);
return 0;
}
and for "normal" operation, changing this:
/* note: do NOT use "wt" here! -- defer to underlying
* mount type on cygwin
*/
if ((shwrapper = fopen (newargz[1], "w")) == 0)
to
/* always use binary mode */
if ((shwrapper = fopen (newargz[1], "wb")) == 0)
Both cygwin and msys's shell will work with unix line endings,
regardless of cygwin's underlying mount type, etc.
Of course, both of these suggestions (setmode, and using "wb") are
win32-isms, and will only work as written above if we continue to use
$LTCC as described below:
# 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.
$opt_dry_run || {
$LTCC $LTCFLAGS -o $cwrapper $cwrappersource
$STRIP $cwrapper
}
As Ralf has pointed out, the comment above is not currently correct: we
currently do need to execute the binary wrapper, even if we don't want
to run the actual target, because the next step is:
# Now, create the wrapper script for func_source use:
$opt_dry_run || {
$cwrapper --lt-dump-script >
$func_ltwrapper_scriptname_result
}
=== emulator problem
(1) guard win32-isms in the binary wrapper source code against non-win32
build environment
(2) use build environment compiler to compile binary wrapper
(3) this means that you CAN'T use an emulator environment at all, if you
wanted to run the tests -- because the emulator won't be able to execute
the binary wrappers
Okay. So that's not really a solution. What we really need is the
capability to extract (or emit) the shell wrapper during the link phase
(or earlier), just so libtool can source it back in and parse the contents.
One important note: for win32 targets, there are TWO different copies
(with different names) of the shell wrapper. One is created during the
link phase, and is only present so that it can be sourced back in by
libtool and parsed. The other (ephemeral) copy is (re)created each time
the binary wrapper is executed, and the binary wrapper then execs it.
Our problem is the first one. How about, when cross-compiling for win32
targets, keep most things as they are (with perhaps some of the
line-ending changes described above). However, just change this bit:
# Now, create the wrapper script for func_source use:
func_ltwrapper_scriptname $cwrapper
$RM $func_ltwrapper_scriptname_result
trap "$RM $func_ltwrapper_scriptname_result; exit
$EXIT_FAILURE" 1 2 15
$opt_dry_run || {
$cwrapper --lt-dump-script >
$func_ltwrapper_scriptname_result
}
so that when cross-compiling for win32, we use the "normal" method of
creating $func_ltwrapper_scriptname_result -- direct creation from libtool:
func_emit_wrapper no > $func_ltwrapper_scriptname_result
Here's a possible (completely untested) patch.
--
Chuck
Index: ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.99
diff -u -r1.99 ltmain.m4sh
--- ltmain.m4sh 5 Mar 2008 20:14:43 - 1.99
+++ ltmain.m4sh 8 Mar 2008 18:54:53 -
@@ -2513,6 +2513,7 @@
#ifdef _MSC_VER
# include
# include
+# include
#else
# include
# include
@@ -2523,6 +2524,7 @@
#include
#include
#include
+#include
#include
#if defined(PATH_MAX)
@@ -2556,6 +2558,7 @@
#if defined (_WIN32) || defined (__MSDOS__) || defined (__DJGPP__) || \
defined (__OS2__)
# define HAVE_DOS_BASED_FILE_SYSTEM
+# define FOPEN_WB "wb"
# ifndef DIR_SEPARATOR_2
# define DIR_SEPARATOR_2 '\\'
# endif
@@ -2577,6 +2580,17 @@
# define IS_PATH_SEPARATOR(ch) ((ch) == PATH_SEPARATOR_2)
#endif /* PATH_SEPARATOR_2 */
+#ifdef __CYGWIN__
+# define FOPEN_WB "wb"
+#endif
+
+#ifndef FOPEN_WB
+# define FOPEN_WB "w"
+#endif
+#ifndef _O_BINARY
+# define _O_BINARY 0
+#endif
+
#define XMA
[patch] 1.5.26 do echo=echo if necessary
Earlier today, i built Libtool 2.2 and was ready to install it, but then had second thoughts about using it w/ Automake 1.9.6. So, i built Automake 1.10.1 and saw "make check" result in 14 errors. Investigating the first of these, depcomp4.test, i see that for some reason, testSubDir/libtool around line 810 uses `$echo', but the shell variable `echo' has no value. This is w/ Libtool 1.5.24, so i built Libtool 1.5.26 and installed it, in the blind hope that "Bug Fixes" (in the NEWS) would include some relief. Alas, no. So, below is a quick patch that seems to work. Here is a ChangeLog entry for this tiny change: * ltmain.sh: Prior to parsing the command line "once, thoroughly", make sure shell variable `echo' has some sane value. I hope it (or a more suitable reworking) will appear in a 1.5.x release. That way, i can then install Automake 1.10.1 w/ Libtool 1.5.x, and subsequently Libtool 2.2.x, for peace of mind. thi diff -u libtool-1.5.26/ltmain.sh.ORIG libtool-1.5.26/ltmain.sh --- libtool-1.5.26/ltmain.sh.ORIG 2008-02-01 17:39:51.0 +0100 +++ libtool-1.5.26/ltmain.sh 2008-03-08 18:05:15.0 +0100 @@ -426,6 +426,9 @@ disable_libs=no +# For some reason, echo is (sometimes?) not set. --ttn +if test "X$echo" = X ; then echo=echo ; fi + # Parse our command line options once, thoroughly. while test "$#" -gt 0 do Diff finished. Sat Mar 8 18:06:22 2008 ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: cross compilation to w32
Hi Gary, * Gary V. Vaughan wrote on Sat, Mar 08, 2008 at 05:39:38PM CET: > On 8 Mar 2008, at 07:03, Ralf Wildenhues wrote: >> we have a couple of problems wrt. cross compilation to w32 in 2.2. >> When I cross-compile from GNU/Linux to MinGW using Debian's mingw32 >> packages (i586-mingw32msvc-gcc etc.), then link mode already >> requires executing a host program; for example: [...] >> This means that building will fail on systems without a simulator. [...] >> Does anybody see easy ways out? > > Shouldn't the cwrapper be compiled with the host compiler? It looks as > though it isn't at the moment... It is. With our new scheme in 2.2 however, the wrapper is also *executed* already at link time, rather than only at run time. That is the gist of the first problem for users without a simulator. Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: cross compilation to w32
Hallo Ralf, On 8 Mar 2008, at 07:03, Ralf Wildenhues wrote: we have a couple of problems wrt. cross compilation to w32 in 2.2. When I cross-compile from GNU/Linux to MinGW using Debian's mingw32 packages (i586-mingw32msvc-gcc etc.), then link mode already requires executing a host program; for example: cd tests/demo /bin/sh -x ./libtool --tag=CC --mode=link i586-mingw32msvc-gcc -g -O2 -export-dynamic -dlpreopen libhello.la -L/usr/i586-mingw32msvc/ lib -o helldl.exe dlmain.o [...] + ./helldl.exe --lt-dump-script Wine exited with a successful status + exit 0 This means that building will fail on systems without a simulator. The other problem I've stumbled over so far is this one: the *_ltshwrapper file has DOS line endings. This causes 'make install' to fail, because the native /bin/sh cannot parse the script: /bin/sh ./libtool --mode=install /usr/bin/install -c 'hell.exe' '/ home/ralf/download/cvs/libtool/HEAD/build-mingw/_inst/bin/hell.exe' : command not foundapper: line 2: : command not foundapper: line 11: : command not foundapper: line 16: ./.libs/hell_ltshwrapper: line 26: syntax error near unexpected token `newline' ./.libs/hell_ltshwrapper: line 26: ` case `(set -o) 2>/dev/null` in *posix*) se' -o posix;; esac libtool: install: invalid libtool wrapper script `./.libs/ hell_ltshwrapper' Does anybody see easy ways out? Shouldn't the cwrapper be compiled with the host compiler? It looks as though it isn't at the moment... Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ PGP.sig Description: This is a digitally signed message part ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 55 failed with as-needed
Hi, > First, how did you stumble over this failure? Did you explicitly > configure with LDFLAGS=-Wl,--as-needed? Yes, something like 'LDFLAGS="-Wl,--as-needed" ./configure' (in fact, at first, I've done this a different way because it's automated with the package manager, but that's more or less what it does in the end) > If yes, is that the only > failure you get with that setting Well, test 64 fails too but I thought this was due to test 55 failing: 64: Run tests with low max_cmd_len FAILED(cmdline_wrap.at:43) [...] ERROR: 63 tests were run, 5 failed (3 expected failures). 1 test was skipped. > and if no, does gentoo set that > by default now in some way (which)? not really; it's not even officially supported that people set this on their own ;) [1] Regards, Alexis. [1] http://www.gentoo.org/proj/en/qa/asneeded.xml signature.asc Description: PGP signature ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 55 failed with as-needed
Hi Alexis, * Alexis Ballier wrote on Sat, Mar 08, 2008 at 02:50:09PM CET: > > Perhaps it's the desired behavior, but I get a failure on test 55 when > using -Wl,--as-needed in LDFLAGS (and its ok if I remove it). > From my poor understanding of template.at, the test is run for the case > when libb does not depend on liba and when linking the main program > against both libb and liba, liba gets dropped but libb needs it, thus > the linking failure. Anyway, I thought it was worth reporting it. Thank you for the report. That's interesting, for several reasons. First, how did you stumble over this failure? Did you explicitly configure with LDFLAGS=-Wl,--as-needed? If yes, is that the only failure you get with that setting, and if no, does gentoo set that by default now in some way (which)? Second, this corresponds to a failure Markus Duft had with his w32 patch series. More data points are always helpful Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
[libtool 2.2] testsuite: 55 failed with as-needed
Hi,
Perhaps it's the desired behavior, but I get a failure on test 55 when
using -Wl,--as-needed in LDFLAGS (and its ok if I remove it).
From my poor understanding of template.at, the test is run for the case
when libb does not depend on liba and when linking the main program
against both libb and liba, liba gets dropped but libb needs it, thus
the linking failure. Anyway, I thought it was worth reporting it.
(log below)
Regards,
Alexis.
# -*- compilation -*-
55. template.at:126: testing ...
./template.at:127: { test -n "$CXX" && test "X$CXX" != Xno; } || (exit 77)
./template.at:127: test "X$CXX" != Xg++ || (g++ -v >/dev/null 2>&1) || (exit 77)
./template.at:220: $CXX $CPPFLAGS $CXXFLAGS -c -o $main_o ../src/sub/main.cpp
stderr:
stdout:
./template.at:230: $LIBTOOL --tag=CXX --mode=compile $CXX $CPPFLAGS $CXXFLAGS
-c -o lib/a.lo ../src/lib/a.cpp
stderr:
stdout:
libtool: compile: x86_64-pc-linux-gnu-g++ -I../src/lib -I../src/lib2
-march=athlon64 -O2 -pipe -g -ggdb -c ../src/lib/a.cpp -fPIC -DPIC -o
lib/.libs/a.o
libtool: compile: x86_64-pc-linux-gnu-g++ -I../src/lib -I../src/lib2
-march=athlon64 -O2 -pipe -g -ggdb -c ../src/lib/a.cpp -o lib/a.o >/dev/null
2>&1
./template.at:232: $LIBTOOL --tag=CXX --mode=compile $CXX $CPPFLAGS $CXXFLAGS
-c -o lib2/b.lo ../src/lib2/b.cpp
stderr:
stdout:
libtool: compile: x86_64-pc-linux-gnu-g++ -I../src/lib -I../src/lib2
-march=athlon64 -O2 -pipe -g -ggdb -c ../src/lib2/b.cpp -fPIC -DPIC -o
lib2/.libs/b.o
libtool: compile: x86_64-pc-linux-gnu-g++ -I../src/lib -I../src/lib2
-march=athlon64 -O2 -pipe -g -ggdb -c ../src/lib2/b.cpp -o lib2/b.o >/dev/null
2>&1
./template.at:234: $CXX $CPPFLAGS $CXXFLAGS -c ../src/sub/main.cpp
stderr:
stdout:
./template.at:237: $LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o
lib/liba.la lib/a.lo
stderr:
stdout:
libtool: link: x86_64-pc-linux-gnu-ar cru lib/.libs/liba.a lib/.libs/a.o
libtool: link: x86_64-pc-linux-gnu-ranlib lib/.libs/liba.a
libtool: link: ( cd "lib/.libs" && rm -f "liba.la" && ln -s "../liba.la"
"liba.la" )
./template.at:239: $LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o
lib2/libb.la lib2/b.lo
stderr:
stdout:
libtool: link: x86_64-pc-linux-gnu-ar cru lib2/.libs/libb.a lib2/.libs/b.o
libtool: link: x86_64-pc-linux-gnu-ranlib lib2/.libs/libb.a
libtool: link: ( cd "lib2/.libs" && rm -f "libb.la" && ln -s "../libb.la"
"libb.la" )
./template.at:241: $LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o
sub/main $main_o lib2/libb.la lib/liba.la
stderr:
stdout:
libtool: link: x86_64-pc-linux-gnu-g++ -march=athlon64 -O2 -pipe -g -ggdb
-Wl,--as-needed -o sub/main sub/main.o lib2/.libs/libb.a lib/.libs/liba.a
./template.at:243: ./sub/main; lt_status=$?; if test $lt_status -eq 0; then :;
elif test "X$host" != "X$build" && \
{ test -x "./sub/main" || test -x "./sub/main"$EXEEXT; }
then (exit 77); else (exit $lt_status); fi
./template.at:246: $LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o
lib2/libb.la lib2/b.lo -rpath /foo
stderr:
stdout:
libtool: link: rm -fr lib2/.libs/libb.a lib2/.libs/libb.la
libtool: link: x86_64-pc-linux-gnu-g++ -shared -nostdlib
/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.3/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.3/crtbeginS.o lib2/.libs/b.o
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.3
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.3/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.3/../../../../x86_64-pc-linux-gnu/lib
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.3/../../.. -lstdc++ -lm -lc -lgcc_s
/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.3/crtendS.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.3/../../../../lib64/crtn.o
-march=athlon64 -Wl,--as-needed -Wl,-soname -Wl,libb.so.0 -o
lib2/.libs/libb.so.0.0.0
libtool: link: (cd "lib2/.libs" && rm -f "libb.so.0" && ln -s "libb.so.0.0.0"
"libb.so.0")
libtool: link: (cd "lib2/.libs" && rm -f "libb.so" && ln -s "libb.so.0.0.0"
"libb.so")
libtool: link: x86_64-pc-linux-gnu-ar cru lib2/.libs/libb.a lib2/b.o
libtool: link: x86_64-pc-linux-gnu-ranlib lib2/.libs/libb.a
libtool: link: ( cd "lib2/.libs" && rm -f "libb.la" && ln -s "../libb.la"
"libb.la" )
./template.at:248: $LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o
sub/main $main_o lib2/libb.la lib/liba.la
stderr:
stdout:
libtool: link: x86_64-pc-linux-gnu-g++ -march=athlon64 -O2 -pipe -g -ggdb
-Wl,--as-needed -o sub/.libs/main sub/main.o lib2/.libs/libb.so
lib/.libs/liba.a -Wl,-rpath -Wl,/foo
./template.at:250: ./sub/main; lt_status=$?; if test $lt_status -eq 0; then :;
elif test "X$host" != "X$build" && \
{ test -x "./sub/main" || test -x "./sub/main"$EXEEXT; }
then (exit 77); else (exit $lt_status); fi
./template.at:254: $LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o
lib/liba.la lib/a.lo -rpath /foo
stderr:
stdout:
libtool: link: rm -fr lib/.libs/liba.a lib/.libs/liba.la
libtool: l
Re: [libtool 2.2] testsuite: 34 failed
Ralf Wildenhues wrote: On Sat, Mar 08, 2008 at 09:58:38AM +0100, Roberto Bagnara wrote: Ralf Wildenhues wrote: What I instead meant was: the installed libltdl.la file is missing, but the libltdl.so.7 file is still present, as is the ltdl.h header in the include directory. Does that still match your setup? The problem is that I have installed 2.2 and then the versions patched as you indicated on the same path. So, even if something that belonged to 2.1.b was still there when I say 2.2's `make check' failing, now it has been overwritten. OK. Also, are things working for you with 2.3a now? Things work with 2.2 + your patches. However, I am of course willing to test with 2.3a. Where is it? I have looked in There is no release 2.3a. 2.3a is the term for the CVS version, i.e., currently CVS HEAD. There will however be a 2.2.2 in a few weeks. CVS HEAD passes all tests here and seem to work OK for our project. Just to make sure I have understood you right: if with whatever you currently have, you run make check-local TESTSUITEFLAGS="-v -d -x -k AC_WITH_LTDL" then this passes for you now? Yes. Cheers, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED] ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 34 failed
On Sat, Mar 08, 2008 at 09:58:38AM +0100, Roberto Bagnara wrote: > Ralf Wildenhues wrote: > > > >What I instead meant was: the installed libltdl.la file is missing, > >but the libltdl.so.7 file is still present, as is the ltdl.h header > >in the include directory. > > > >Does that still match your setup? > > The problem is that I have installed 2.2 and then the versions patched > as you indicated on the same path. So, even if something that belonged > to 2.1.b was still there when I say 2.2's `make check' failing, now it > has been overwritten. OK. > >Also, are things working for you with 2.3a now? > > Things work with 2.2 + your patches. However, I am of course willing to test with 2.3a. Where is it? I have looked in There is no release 2.3a. 2.3a is the term for the CVS version, i.e., currently CVS HEAD. There will however be a 2.2.2 in a few weeks. Just to make sure I have understood you right: if with whatever you currently have, you run make check-local TESTSUITEFLAGS="-v -d -x -k AC_WITH_LTDL" then this passes for you now? Thanks, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 34 failed
Ralf Wildenhues wrote: On Sat, Mar 08, 2008 at 08:27:38AM +0100, Roberto Bagnara wrote: Ralf Wildenhues wrote: I can reproduce this error under the following circumstances: A libltdl 2.1 or newer has previously been installed in a place where the preprocessor and the link editor can find headers resp. library (suitable CPPFLAGS=-I... and LDFLAGS=-L... count, too), but the libltdl.la file is missing in the installation, and also the runtime linker does not search the installed location of libltdl.so.7 by default (and -R.../-Wl,-rpath,... have not been added). Does that match your setup? If yes, who removed the installed libltdl.la file, and why? yes, I believe this matches my setup. I had installed Libtool 2.1.b; nothing worked for me so, since I had no time to investigate further, I uninstalled it (not the proper way, I guess) and went back to Libtool 1.5.24. But if you used "make uninstall", then there should be no traces left. I think I have used `make uninstall', but I may be wrong. What I instead meant was: the installed libltdl.la file is missing, but the libltdl.so.7 file is still present, as is the ltdl.h header in the include directory. Does that still match your setup? The problem is that I have installed 2.2 and then the versions patched as you indicated on the same path. So, even if something that belonged to 2.1.b was still there when I say 2.2's `make check' failing, now it has been overwritten. Also, are things working for you with 2.3a now? Things work with 2.2 + your patches. However, I am of course willing to test with 2.3a. Where is it? I have looked in http://alpha.gnu.org/gnu/libtool/ and http://ftp.gnu.org/gnu/libtool/ but could not find it. Cheers, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED] ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
