Re: bug-report
Hello Sergey, * Sergey Pribilskiy wrote on Mon, Nov 05, 2007 at 09:51:33PM CET: [...] configure:2033: checking for a BSD-compatible install configure:2089: result: /usr/bin/install -c -o root -g wheel configure:2100: checking whether build environment is sane configure:2137: error: newly created file is older than distributed files! Check your system clock You should do just that and set your system clock. Then this error should disappear. Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Bug report as requested.
On Thu, 11 Jan 2007, Ralf Wildenhues wrote: * Hugh Sasse wrote on Thu, Jan 11, 2007 at 10:51:42AM CET: [...] Now that I don't understand. Why does the link succeed now? Did you change anything other than passing -v? Not knowingly. Since then I have built gfortran on the one machine and guile is happier about libraries. 3.4.3? Oh, I remember having problems building fortran because of getting GMP and MPFR to work correctly. It doesn't look like a GMP/MPFR related problem to me. Well, I succeeded in building gcc with fortran with its own version of GCC. So maybe now I have those working I should try to rebuild GCC-4.1.0 with fortran before proceeding? Dunno, but I don't see why. I simply don't understand why g77 -g -O2 -o fprogram fprogram.o ./.libs/libfoo.a should fail but g77 -v -g -O2 -o fprogram fprogram.o ./.libs/libfoo.a should succeed? But maybe I have misunderstood something here. Well, I think I'll let this go for now. I've not managed to build Guile yet, but I don't seem to have all the necessary functions. Cheers, Ralf Thank you for helping me get this far. I'll now seek help from the guile people. Hugh ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Bug report as requested.
On Wed, 10 Jan 2007, Ralf Wildenhues wrote: * Hugh Sasse wrote on Wed, Jan 10, 2007 at 11:25:14AM CET: On Tue, 9 Jan 2007, Ralf Wildenhues wrote: /bin/bash ./libtool --tag=F77 --mode=link g77 -g -O2 -o fprogram fprogram.o libfoo.la g77 -g -O2 -o fprogram fprogram.o ./.libs/libfoo.a /usr/local/bin/ld: crt1.o: No such file: No such file or directory collect2: ld returned 1 exit status Hmm. This looks like your g77 installation is a bit broken. Does it work fine for other uses? Can you go into the f77demo directory and issue /bin/bash ./libtool --tag=F77 --mode=link g77 -v -g -O2 -o fprogram fprogram.o libfoo.la bash-2.05$ /bin/bash ./libtool --tag=F77 --mode=link g77 -v -g -O2 -o fprogram fprogram.o libfoo.la g77 -v -g -O2 -o fprogram fprogram.o ./.libs/libfoo.a Driving: g77 -v -g -O2 -o fprogram fprogram.o ./.libs/libfoo.a -lfrtbegin -lg2c -lm -shared-libgcc Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.3/specs Configured with: /scratch/hgs/gcc-3.4.3/configure --with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld --enable-languages=c,c++,f77,objc --disable-nls Thread model: posix gcc version 3.4.3 /usr/local/libexec/gcc/sparc-sun-solaris2.9/3.4.3/collect2 -V -Y P,/usr/ccs/lib:/usr/lib -rpath-link /usr/lib -Qy -o fprogram /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.3/crt1.o /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.3/crti.o /usr/ccs/lib/values-Xa.o /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.3/crtbegin.o -L/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.3 -L/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.3/../../../../sparc-sun-solaris2.9/lib -L/usr/ccs/bin -L/usr/ccs/lib -L/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.3/../../.. fprogram.o ./.libs/libfoo.a -lfrtbegin -lg2c -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc -lc /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.3/crtend.o /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.3/crtn.o GNU ld version 2.17 Supported emulations: elf32_sparc elf64_sparc bash-2.05$ 3.4.3? Oh, I remember having problems building fortran because of getting GMP and MPFR to work correctly. So maybe now I have those working I should try to rebuild GCC-4.1.0 with fortran before proceeding? I hope not, but if supported formats is the problem I suppose I'll have to. to find out where crt1.o should be, and maybe also why it isn't there? (I'd guess something like /usr/local/lib/gcc/...sparc.../3.4.6/../../../../lib/crt1.o ) bash-2.05$ find /usr/local/lib/gcc -name crt1.o -print /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.3/sparcv9/crt1.o /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.3/crt1.o /usr/local/lib/gcc/sparc-sun-solaris2.9/4.0.2/crt1.o /usr/local/lib/gcc/sparc-sun-solaris2.9/4.0.2/sparcv9/crt1.o /usr/local/lib/gcc/sparc-sun-solaris2.9/4.1.0/crt1.o /usr/local/lib/gcc/sparc-sun-solaris2.9/4.1.0/sparcv9/crt1.o bash-2.05$ [...] FAIL: f77demo-make.test === Running f77demo-exec.test You must run f77demo-make.test before running ./f77demo-exec.test SKIP: f77demo-exec.test [...] The errors about You must run f77demo-make.test before... seem a bit odd to me, since we have just done that... Yeah, that's right. The testsuite can't distinguish the case where the required test failed or wasn't run at all. For CVS Libtool, we're slowly moving to an Autotest-based testsuite... OK... Cheers, Ralf Thank you, Hugh ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Bug report as requested.
Hello Hugh, Thanks for the bug report. * Hugh Sasse wrote on Tue, Jan 09, 2007 at 11:07:54AM CET: libtool-1.5.22 on Sun-sparc-solaris2.9 PASS: f77demo-static.test FAIL: f77demo-make.test SKIP: f77demo-exec.test PASS: f77demo-conf.test FAIL: f77demo-make.test SKIP: f77demo-exec.test PASS: f77demo-shared.test FAIL: f77demo-make.test SKIP: f77demo-exec.test Anything else I need to tell you for this to be useful? Yes. Please run make check VERBOSE=yes \ TESTS=f77demo-static.test f77demo-make.test f77demo-exec.test \ f77demo-conf.test f77demo-make.test f77demo-exec.test \ f77demo-shared.test f77demo-make.test f77demo-exec.test and post the output. Probably you want to use gmake rather than Solaris make. Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Bug-Report libtool-1.5.20
[ I have put the bug-libtool list in Cc: again ] Hi Christof, * Nuber, Christof wrote on Tue, Nov 29, 2005 at 09:26:41AM CET: Von: Ralf Wildenhues * Nuber, Christof wrote on Mon, Nov 28, 2005 at 10:44:52AM CET: I tried to run make check for libtool-1.5.20 on a Linux-2.4.21-37 ELsmp-Kernel (RedHat WS 3.6) on a HP xw 9300 (2x AMD Opteron 275), x64_86-Processor. 5 (mdemo-make.test, pdemo-inst.test, pdemo-exec.test, mdemo2-exec.test, tagdemo-exec.test) of 109 tests failed, 3 (mdemo-exec.test, mdemo-inst.test, demo-nopic.test) were not run. Thank you for the bug report. We need a bit more information. I couldn't reconstruct the bug. It occured while I was upgrading m4, libtools, autoconf and automake (in that order). After upgrading autoconf and automake I didn't get the message anymore. Sorry that I can't give you more information. Well, if you could tell us which the previous installed autoconf and automake versions were, that would likely be enough information to reproduce the bug. Then we can decide whether we need to do something about it. Thank you. For the next upgrade round, it's probably more advisable to upgrade autoconf before automake before libtool. OTOH, given that m4-2.0 will likely depend on libtool-2.0, and autoconf's next major version *may* depend on m4-2.0, this can't be said for certain, *iff* you are upgrading CVS versions which need bootstrapping. If you instead download tarballs, or simply upgrade from some packaging system, you should be fine either way. Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Bug-Report libtool-1.5.20
Hi Chris, * Nuber, Christof wrote on Mon, Nov 28, 2005 at 10:44:52AM CET: I tried to run make check for libtool-1.5.20 on a Linux-2.4.21-37 ELsmp-Kernel (RedHat WS 3.6) on a HP xw 9300 (2x AMD Opteron 275), x64_86-Processor. 5 (mdemo-make.test, pdemo-inst.test, pdemo-exec.test, mdemo2-exec.test, tagdemo-exec.test) of 109 tests failed, 3 (mdemo-exec.test, mdemo-inst.test, demo-nopic.test) were not run. If you need more information (which I assume), please let me know. Thank you for the bug report. We need a bit more information. Please rerun verbosely, like this: make check VERBOSE=x 21 | tee checklog and send the log, preferably packed with bzip2 or gzip. If you want to avoid rerunning all tests, you can limit yourself to the corresponding test groups; most libtool tests are supposed to be run in groups: for example, this TESTS=mdemo-conf.test mdemo-make.test mdemo-exec.test mdemo-inst.test mdemo-unst.test would be one test group; it is important whether mdemo-conf or mdemo-static or mdemo-shared ran before the failing mdemo-make test. Thanks, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
