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 [email protected] 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 [email protected] 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 [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 34 failed
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. 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? Also, are things working for you with 2.3a now? Thanks, Ralf ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 34 failed
Ralf Wildenhues wrote:
Hello Roberto,
your posts are good sources of bug reports ...
* Roberto Bagnara wrote on Sun, Mar 02, 2008 at 08:48:07AM CET:
## --- ##
## libtool 2.2 test suite. ##
## --- ##
[...]
## ##
## Summary of the failures. ##
## ##
Failed tests:
libtool 2.2 test suite test groups:
NUM: FILE-NAME:LINE TEST-GROUP-NAME
KEYWORDS
34: old-m4-iface.at:107 AC_WITH_LTDL
libtoolize automake autoconf
[...]
34. old-m4-iface.at:107: testing ...
libtoolize: putting auxiliary files in `.'.
[...]
checking whether libtool supports -dlopen/-dlpreopen... yes
checking for ltdl.h... yes
checking whether lt_dlinterface_register is declared... yes
checking for lt_dlinterface_register in -lltdl... yes
checking where to find libltdl headers...
checking where to find libltdl library... -lltdl
[...]
./old-m4-iface.at:153: $MAKE
[...]
/bin/sh ./libtool --mode=link gcc -no-undefined -g -O2 -o ltdldemo main.o
-dlopen module.la -lltdl
libtool: link: rm -f .libs/ltdldemo.nm .libs/ltdldemo.nmS .libs/ltdldemo.nmT
libtool: link: (cd .libs && gcc -g -O2 -c -fno-builtin "ltdldemoS.c")
libtool: link: rm -f ".libs/ltdldemoS.c" ".libs/ltdldemo.nm" ".libs/ltdldemo.nmS"
".libs/ltdldemo.nmT"
libtool: link: gcc -g -O2 -o ltdldemo main.o .libs/ltdldemoS.o -lltdl
libtool: link: rm -f ".libs/ltdldemoS.o"
make[4]: Leaving directory
`/usr/local/distrib/libtool-2.2/tests/testsuite.dir/34'
./old-m4-iface.at:156: ./ltdldemo; lt_status=$?; if test $lt_status -eq 0; then
:;
elif test "X$host" != "X$build" && \
{ test -x "./ltdldemo" || test -x "./ltdldemo"$EXEEXT; }
then (exit 77); else (exit $lt_status); fi
--- /dev/null 2008-02-27 15:51:00.483962769 +0100
+++ /usr/local/distrib/libtool-2.2/tests/testsuite.dir/at-stderr
2008-03-02 08:28:27.0 +0100
@@ -0,0 +1 @@
+./ltdldemo: error while loading shared libraries: libltdl.so.7: cannot open
shared object file: No such file or directory
stdout:
./old-m4-iface.at:156: exit code was 127, expected 0
34. old-m4-iface.at:107: 34. AC_WITH_LTDL (old-m4-iface.at:107): FAILED
(old-m4-iface.at:156)
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?
Dear Ralf,
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.
Thanks a lot,
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
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 34 failed
Hello Roberto,
your posts are good sources of bug reports ...
* Roberto Bagnara wrote on Sun, Mar 02, 2008 at 08:48:07AM CET:
> ## --- ##
> ## libtool 2.2 test suite. ##
> ## --- ##
[...]
> ## ##
> ## Summary of the failures. ##
> ## ##
> Failed tests:
> libtool 2.2 test suite test groups:
>
> NUM: FILE-NAME:LINE TEST-GROUP-NAME
> KEYWORDS
>
> 34: old-m4-iface.at:107 AC_WITH_LTDL
> libtoolize automake autoconf
[...]
> 34. old-m4-iface.at:107: testing ...
> libtoolize: putting auxiliary files in `.'.
[...]
> checking whether libtool supports -dlopen/-dlpreopen... yes
> checking for ltdl.h... yes
> checking whether lt_dlinterface_register is declared... yes
> checking for lt_dlinterface_register in -lltdl... yes
> checking where to find libltdl headers...
> checking where to find libltdl library... -lltdl
[...]
> ./old-m4-iface.at:153: $MAKE
[...]
> /bin/sh ./libtool --mode=link gcc -no-undefined -g -O2 -o ltdldemo main.o
> -dlopen module.la -lltdl
> libtool: link: rm -f .libs/ltdldemo.nm .libs/ltdldemo.nmS .libs/ltdldemo.nmT
> libtool: link: (cd .libs && gcc -g -O2 -c -fno-builtin "ltdldemoS.c")
> libtool: link: rm -f ".libs/ltdldemoS.c" ".libs/ltdldemo.nm"
> ".libs/ltdldemo.nmS" ".libs/ltdldemo.nmT"
> libtool: link: gcc -g -O2 -o ltdldemo main.o .libs/ltdldemoS.o -lltdl
> libtool: link: rm -f ".libs/ltdldemoS.o"
> make[4]: Leaving directory
> `/usr/local/distrib/libtool-2.2/tests/testsuite.dir/34'
> ./old-m4-iface.at:156: ./ltdldemo; lt_status=$?; if test $lt_status -eq 0;
> then :;
> elif test "X$host" != "X$build" && \
> { test -x "./ltdldemo" || test -x "./ltdldemo"$EXEEXT; }
> then (exit 77); else (exit $lt_status); fi
> --- /dev/null 2008-02-27 15:51:00.483962769 +0100
> +++ /usr/local/distrib/libtool-2.2/tests/testsuite.dir/at-stderr
> 2008-03-02 08:28:27.0 +0100
> @@ -0,0 +1 @@
> +./ltdldemo: error while loading shared libraries: libltdl.so.7: cannot open
> shared object file: No such file or directory
> stdout:
> ./old-m4-iface.at:156: exit code was 127, expected 0
> 34. old-m4-iface.at:107: 34. AC_WITH_LTDL (old-m4-iface.at:107): FAILED
> (old-m4-iface.at:156)
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?
Thanks,
Ralf
___
Bug-libtool mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 34 failed
Ralf Wildenhues wrote: * Roberto Bagnara wrote on Sun, Mar 02, 2008 at 08:48:07AM CET: I got errors on a Fedora 7 system (x86_64): the log file is attached. I have also tried using Libtool 2.2 on one of my projets, but I get the following: /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -I/home/roberto/ppl/ppl/src -I.. -I/home/roberto/ppl/ppl/src-g -frounding-math -W -Wall -MT Box.lo -MD -MP -MF .deps/Box.Tpo -c -o Box.lo /home/roberto/ppl/ppl/src/Box.cc ../libtool: line 459: CDPATH: command not found ../libtool: line 1262: func_opt_split: command not found libtool: Version mismatch error. This is libtool 2.2, but the libtool: definition of this LT_INIT comes from an older release. libtool: You should recreate aclocal.m4 with macros from libtool 2.2 libtool: and run autoconf again. I think I did that on entirely new directories and after running `autoreconf -f' to recreate (among other things), aclocal.m4. What am I missing? Which Autoconf, M4 versions were used? What says grep LT_INIT aclocal.m4 m4/libtool.m4 (modify the latter to point at the libtool.m4 file that's copied into your project if any). Hi Ralf, this was entirely my fault: I did something stupid in my first attempt of switching from Libtool 1.5.24 to Libtool 2.2 (m4/libtool.m4 was not even there). However, things still do not seem to work properly for me. Trying to understand what is going on, I have distilled the following: $ cat mycommand #!/bin/sh echo "mycommand invoked with argument '$1'" $ mycommand ciao mycommand invoked with argument 'ciao' $ ./libtool --mode=execute mycommand ciao mycommand invoked with argument '/home/roberto/tppl/' $ Note that /home/roberto/tppl/ is the directory where the libtool script is located. I can also do $ cd interfaces/ $ ../libtool --mode=execute ../mycommand ciao mycommand invoked with argument '/home/roberto/tppl/' Is this behavior normal? ./libtool is what has been created at configure time and a bzipped version of it is attached to this file. Still looking at your the testsuite failure (but it's anyway an issue separate from the above). Cheers, and thanks for the report, Thanks to you! Best, Roberto P.S. In ./libtool there is the line # Generated automatically by config.status (GNU ppl) 0.10pre16 `ppl' is indeed the short name of the project. I don't know why it is preceded by "GNU". -- 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 [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 34 failed
Hello Roberto, * Roberto Bagnara wrote on Sun, Mar 02, 2008 at 08:48:07AM CET: > > I got errors on a Fedora 7 system (x86_64): the log file > is attached. I have also tried using Libtool 2.2 on one > of my projets, but I get the following: > > /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. > -I/home/roberto/ppl/ppl/src -I.. -I/home/roberto/ppl/ppl/src-g > -frounding-math -W -Wall -MT Box.lo -MD -MP -MF .deps/Box.Tpo -c -o Box.lo > /home/roberto/ppl/ppl/src/Box.cc > ../libtool: line 459: CDPATH: command not found > ../libtool: line 1262: func_opt_split: command not found > libtool: Version mismatch error. This is libtool 2.2, but the > libtool: definition of this LT_INIT comes from an older release. > libtool: You should recreate aclocal.m4 with macros from libtool 2.2 > libtool: and run autoconf again. > > I think I did that on entirely new directories and after running > `autoreconf -f' to recreate (among other things), aclocal.m4. > What am I missing? Which Autoconf, M4 versions were used? What says grep LT_INIT aclocal.m4 m4/libtool.m4 (modify the latter to point at the libtool.m4 file that's copied into your project if any). Still looking at your the testsuite failure (but it's anyway an issue separate from the above). Cheers, and thanks for the report, Ralf ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
