[sr #110849] make check darwin.at test fails on Linux

Update of sr #110849 (group libtool): Open/Closed:Open => Closed ___ Follow-up Comment #2: Closing. If there are still test failures on Ubuntu GNU/Linux, please report them with logs attac

[sr #110849] make check darwin.at test fails on Linux

Update of sr #110849 (group libtool): Status:None => Need Info ___ Reply to this item at: ___ Me

[sr #110849] make check darwin.at test fails on Linux

Follow-up Comment #1, sr #110849 (group libtool): The latest beta release of libtool 2.5.1 passes test 161 on Ubuntu GNU/Linux. Could you retest for this failure? If you attach the testsuite.log for test 161, it may show why the test was failing for you. You can find the log in tests

Re: Number of tests in GNU Libtool 2.4.7 test suite

Hi, On 20/05/2024 14:22, mjjm 1.14.2 wrote: Hello dear developers and programmers and maintainers of GNU Libtool. I just wanted to know how many tests are there in GNU Libtool 2.4.7 test suite? Its already a few hours since I've run the make -k check command. I'm already in the 87

Number of tests in GNU Libtool 2.4.7 test suite

Hello dear developers and programmers and maintainers of GNU Libtool. I just wanted to know how many tests are there in GNU Libtool 2.4.7 test suite? Its already a few hours since I've run the make -k check command. I'm already in the 87th test, I wonder how many are still there left.

[sr #108558] libtool nm test does not really work for W32 versions of nm

Update of sr#108558 (group libtool): Open/Closed:Open => Closed ___ Reply to this item at: ___ Mes

Re: bug#67539: GNU Automake 1.16.5 FAILS one test objc-megademo

On 30 Nov 2023 22:45, Nick Bowler wrote: > Interestingly the libtool manual also says "If [libtool] can't infer a > tag, then it defaults to the configuration for the C language", which is > clearly not the case (it seems what actually happens is that if libtool > can't infer a tag then it exits

Re: bug#67539: GNU Automake 1.16.5 FAILS one test objc-megademo

On 2023-11-30 21:46, Karl Berry wrote: Hi Dennis, libtool: compile: unable to infer tagged configuration Thanks for the report. As you surmise, apparently this needs to be reported to libtool. (Although afaik libtool is currently unmaintained, so I don't know when or if anything will get

Re: [opensoftware] [sr #110849] make check darwin.at test fails on Linux

successful and i was happy to see that there are a lot of tests. I am not sure if i can expect to get an exit code 0 after that or if i just have to check the results if the failed tests really matter to me. But i was curious since it was only the one test which i would have expected to be

Re: [sr #110849] make check darwin.at test fails on Linux

y're running because it's certainly possible that they should be skipped or that the test suite isn't detecting the build/host system properly. On Tue, Mar 7, 2023, 8:45 AM Alex Ameen wrote: > Thanks for the report > > On Mon, Mar 6, 2023, 5:16 PM open software >

Re: [sr #110849] make check darwin.at test fails on Linux

Thanks for the report On Mon, Mar 6, 2023, 5:16 PM open software wrote: > URL: > <https://savannah.gnu.org/support/?110849> > > Summary: make check darwin.at test fails on Linux >Group: GNU Libtool >

[sr #110849] make check darwin.at test fails on Linux

URL: <https://savannah.gnu.org/support/?110849> Summary: make check darwin.at test fails on Linux Group: GNU Libtool Submitter: opensoftware Submitted: Mon 06 Mar 2023 11:16:26 PM UTC Category

Re: binutils 2.28 breaking libtool for test programs when -no-install is used

On 2017-06-01 18:46:56 +0200, Thomas Jahns wrote: > On 06/01/2017 11:09 AM, Vincent Lefevre wrote: > > Perhaps defining the LD_RUN_PATH environment variable instead of > > LD_LIBRARY_PATH could be a workaround, but gold does not support > > it, so that this cannot be a general solution. > > Linkin

Re: binutils 2.28 breaking libtool for test programs when -no-install is used

Thomas Jahns writes: > On 06/01/2017 11:09 AM, Vincent Lefevre wrote: >> On 2017-06-01 09:56:29 +0200, Thomas Jahns wrote: >>> GCC doesn't generate binaries or shared libraries, ld does. Passing >>> -Wl,-rpath,/path/to/dependency/lib >> But this is not automatic. When typing >> $CC program.c

Re: binutils 2.28 breaking libtool for test programs when -no-install is used

On 06/01/2017 11:09 AM, Vincent Lefevre wrote: On 2017-06-01 09:56:29 +0200, Thomas Jahns wrote: GCC doesn't generate binaries or shared libraries, ld does. Passing -Wl,-rpath,/path/to/dependency/lib But this is not automatic. When typing $CC program.c -o program -lmpfr -lgmp (where $CC c

Re: binutils 2.28 breaking libtool for test programs when -no-install is used

On 2017-06-01 08:30:43 -0500, Bob Friesenhahn wrote: > This requires that libtool re-link upon installation if the temporary rpaths > are not wanted. If the temporary rpaths are left in place, then > reliability, performance, and security issues are left baked into the > binaries. > > Are these p

Re: binutils 2.28 breaking libtool for test programs when -no-install is used

On Thu, 1 Jun 2017, Thomas Jahns wrote: GCC doesn't generate binaries or shared libraries, ld does. Passing -Wl,-rpath,/path/to/dependency/lib will do just what's needed (for most people on this list libtool does so for them). This requires that libtool re-link upon installation if the temp

Re: binutils 2.28 breaking libtool for test programs when -no-install is used

On 2017-06-01 09:56:29 +0200, Thomas Jahns wrote: > GCC doesn't generate binaries or shared libraries, ld does. Passing > > -Wl,-rpath,/path/to/dependency/lib But this is not automatic. When typing $CC program.c -o program -lmpfr -lgmp (where $CC can be gcc, tcc or icc, for instance), things

Re: binutils 2.28 breaking libtool for test programs when -no-install is used

On 05/31/2017 01:15 PM, Vincent Lefevre wrote: On 2017-05-31 11:58:05 +0200, Thomas Jahns wrote: On 05/30/2017 06:30 PM, Vincent Lefevre wrote: On 2017-05-30 17:39:14 +0200, Thomas Jahns wrote: I repeat: don't set LD_LIBRARY_PATH, that's the real problem, libtool not working for you is just a

Re: binutils 2.28 breaking libtool for test programs when -no-install is used

On 2017-05-31 11:58:05 +0200, Thomas Jahns wrote: > On 05/30/2017 06:30 PM, Vincent Lefevre wrote: > > On 2017-05-30 17:39:14 +0200, Thomas Jahns wrote: > > > I repeat: don't set LD_LIBRARY_PATH, that's the real problem, libtool not > > > working for you is just a symptom of that. > > > > So, how

Re: binutils 2.28 breaking libtool for test programs when -no-install is used

On 05/30/2017 06:30 PM, Vincent Lefevre wrote: On 2017-05-30 17:39:14 +0200, Thomas Jahns wrote: I repeat: don't set LD_LIBRARY_PATH, that's the real problem, libtool not working for you is just a symptom of that. So, how can I make things work *automatically* under Linux without setting LD_LI

Re: binutils 2.28 breaking libtool for test programs when -no-install is used

On 2017-05-30 17:39:14 +0200, Thomas Jahns wrote: > I repeat: don't set LD_LIBRARY_PATH, that's the real problem, libtool not > working for you is just a symptom of that. So, how can I make things work *automatically* under Linux without setting LD_LIBRARY_PATH? -- Vincent Lefèvre - Web:

Re: binutils 2.28 breaking libtool for test programs when -no-install is used

On 05/30/2017 12:02 PM, Vincent Lefevre wrote: Note that binutils 2.28 is breaking libtool for test programs ("make check") when -no-install is used. I've reported the following bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21476 The problem is that with this version,

binutils 2.28 breaking libtool for test programs when -no-install is used

Hi, Note that binutils 2.28 is breaking libtool for test programs ("make check") when -no-install is used. I've reported the following bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21476 The problem is that with this version, RUNPATH is used instead of RPATH in the execu

Building on an ARM-based NAS fails 'Standalone' test section

to my gratified astonishment after three days grinding away, for the first time ever a 'make' finally completed apparently successfully. However, when I tried to test it using 'make check', I hit a dependency chain: 'make check' for gcc <- autogen <- guile &

[sr #108558] libtool nm test does not really work for W32 versions of nm

Follow-up Comment #11, sr #108558 (project libtool): Don't you want to close this bug? ___ Reply to this item at: ___ Message sent via/by Savannah

[sr #108558] libtool nm test does not really work for W32 versions of nm

Update of sr #108558 (project libtool): Status:None => Done ___ Follow-up Comment #10: Patch pushed. Cheers, Peter ___ Rep

Re: [sr #108558] libtool nm test does not really work for W32 versions of nm

the link, here's the patch in question. Cheers, Peter >From 13aa364c0c66f9f6b41f98772d0735039ac974a1 Mon Sep 17 00:00:00 2001 From: Peter Rosin Date: Tue, 6 May 2014 10:11:34 +0200 Subject: [PATCH] libtool: fix nm test for MSYS/MinGW The check for the -B option of nm does not work as

[sr #108558] libtool nm test does not really work for W32 versions of nm

Follow-up Comment #9, sr #108558 (project libtool): > I have attached a patch that does the safe-safe-safe version. > Does it work for you? Yes, it seems that it does. ___ Reply to this item at:

[sr #108558] libtool nm test does not really work for W32 versions of nm

Follow-up Comment #8, sr #108558 (project libtool): I have attached a patch that does the safe-safe-safe version. Does it work for you? Cheers, Peter (file #31318) ___ Additional Item Attachment: File name: 0001-libtool-fix-nm-test-for

[sr #108558] libtool nm test does not really work for W32 versions of nm

Follow-up Comment #7, sr #108558 (project libtool): Ok, something like this seems safer: mkdir conftest.dir case `"$tmp_nm" -B conftest.dir/nofile` in *conftest.dir/nofile*) blablabla esac rm -rf conftest.dir But I don't know how non-GNU nm behaves, so the safe-safe-safe version only does the ab

[sr #108558] libtool nm test does not really work for W32 versions of nm

Follow-up Comment #6, sr #108558 (project libtool): > Crap. How about just opening a file that is known to not to exist? Alternatively, give nm a real file that is at least 1 byte long (binutils nm checks for filesize being < 1 and fails quietly; having 1 byte makes it say filename (which is wh

[sr #108558] libtool nm test does not really work for W32 versions of nm

Follow-up Comment #5, sr #108558 (project libtool): Hmm, on second thought, that depends on MSYS (and MSYS2) still thinking that an argument starting with more than two slashes is a UNC path (or a switch). That might change if someone points out that ///foo and /foo should be equivalent and that P

[sr #108558] libtool nm test does not really work for W32 versions of nm

Follow-up Comment #4, sr #108558 (project libtool): >> Well, in MSYS2 you can simply do: >> nm -B /dev/thisfilebetternotexistotherwiseyoullbeintrouble >> and get satisfactory results (file name and 'No such file' >> in the output). >> Can't say anything about MSYS1, haven't used it for some time

[sr #108558] libtool nm test does not really work for W32 versions of nm

Follow-up Comment #3, sr #108558 (project libtool): > Well, in MSYS2 you can simply do: > nm -B /dev/thisfilebetternotexistotherwiseyoullbeintrouble > and get satisfactory results (file name and 'No such file' > in the output). > Can't say anything about MSYS1, haven't used it for some time. Tha

[sr #108558] libtool nm test does not really work for W32 versions of nm

Follow-up Comment #2, sr #108558 (project libtool): I was not aware of the extent to which Cygwin is mangling commandlines of pure-W32 programs it runs (since i don't really use Cygwin; i do know it does some kind of conversion; apparently, only in one direction). Evidently, it does not replace /d

[sr #108558] libtool nm test does not really work for W32 versions of nm

is not an ordinary file cygwin$ /bin/i686-pc-mingw32-nm -B /dev/null /bin/i686-pc-mingw32-nm: Warning: '/dev/null' is not an ordinary file If you have native MinGW tools and run libtool from Cygwin (i.e. if you are using a 'fake' or 'lying' cross setup, as describe

[sr #108558] libtool nm test does not really work for W32 versions of nm

URL: <http://savannah.gnu.org/support/?108558> Summary: libtool nm test does not really work for W32 versions of nm Project: GNU Libtool Submitted by: lrn Submitted on: Fri 02 May 2014 05:10:04 AM GMT Category

Re: libtool, multilib and test "duplicate convenience archive names"

On Thursday, October 20, 2011 11:07:13 PM Roumen Petrov wrote: > Hi Andreas and Bo, > > Please could you clarify build of 64-bit system for 32 bit. Hi Roumen, > Roumen Petrov wrote: > > Hello All, > > > > I wonder how to build and test on a 64 bit platfor

Re: libtool, multilib and test "duplicate convenience archive names"

Hi Andreas and Bo, Please could you clarify build of 64-bit system for 32 bit. Roumen Petrov wrote: Hello All, I wonder how to build and test on a 64 bit platform a 32 bit libtool version. First test is to use --build=x86_64-gnu-linux --host=i386-gnu-linux with CC and CXX set to '

libtool, multilib and test "duplicate convenience archive names"

Hello All, I wonder how to build and test on a 64 bit platform a 32 bit libtool version. First test is to use --build=x86_64-gnu-linux --host=i386-gnu-linux with CC and CXX set to 'gcc|g++ -m32', i.e. multilib . The libtool regression suite fail in test case : 25: duplicate c

Re: make test with a program that dlopen()s a shared lib "peer"

On Tue, Mar 29, 2011 at 4:46 AM, Jack Andrews wrote: > Hi Eric, > > That make perfect sense -- only thing is it doesn't seem to work for me: > > ~/effbiae/core(ENV)]$ echo $LD_LIBRARY_PATH > /home/jack/effbiae/core/.libs > ~/effbiae/core(ENV)]$ ./jconsole >   'hi' > hi > ~/effbiae/core(ENV)]$ expo

Re: make test with a program that dlopen()s a shared lib "peer"

--install >>   ./configure >>   make >>   make test >>   make install >> >> but my program dlopen()s a lib which >> i find here: >>    .libs/libj.so >> >> i've read that shared objects are hidden in >> .libs for a reason and that th

Re: make test with a program that dlopen()s a shared lib "peer"

On 03/27/2011 05:46 AM, Jack Andrews wrote: > i want to use the usual sequence of > > autoreconf --install > ./configure > make > make test > make install > > but my program dlopen()s a lib which > i find here: >.libs/libj.so > > i've re

make test with a program that dlopen()s a shared lib "peer"

i want to use the usual sequence of autoreconf --install ./configure make make test make install but my program dlopen()s a lib which i find here: .libs/libj.so i've read that shared objects are hidden in .libs for a reason and that they should be installed prior to use. if

test coverage

I just tried to figure out lcov, and ran the testsuite with --coverage. http://pogma.com/lcov/libltdl/index.html I'll try at some stage to automate the process and do it weekly or so. Peter ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: [2.2.7a Test Results] SLES 10 on pentiumpro with gcc 4.1.2 20070115 (SUSE Linux)

Hi Peter, On 11 Nov 2009, at 11:05, Peter O'Gorman wrote: > On 11/10/2009 03:02 PM, Gary V. Vaughan wrote: >> Sorry again for the delay. >> >> I haven't begun to analyse any of this or the upcoming test results, and may >> not have the time to do so in any

Re: [2.2.7a Test Results] SLES 10 on pentiumpro with gcc 4.1.2 20070115 (SUSE Linux)

On 11/10/2009 03:02 PM, Gary V. Vaughan wrote: Sorry again for the delay. I haven't begun to analyse any of this or the upcoming test results, and may not have the time to do so in any depth before the end of the year. I will, however, provide more details on request, apply proposed pa

[2.2.7a Test Results] RHEL4 on x86_64 with gcc 3.4.6 20060404 (Red Hat 3.4.6-11)

...@gnu.org ... ## - ## ## Test results. ## ## - ## ERROR: 95 tests were run, 32 failed (25 expected failures). 2 tests were skipped. Full VERBOSE=1 results attached. Cheers, -- Gary V. Vaughan (g...@gnu.org) 2009-11-10.cd.akari.log.bz2

[2.2.7a Test Results] RHEL5 on pentiumpro with gcc 4.1.2 20080704 (Red Hat 4.1.2-46)

...@gnu.org ... ## - ## ## Test results. ## ## - ## ERROR: 95 tests were run, 32 failed (25 expected failures). 2 tests were skipped. Full VERBOSE=1 results attached. Cheers, -- Gary V. Vaughan (g...@gnu.org) 2009-11-10.cd.franky.log.bz2

[2.2.7a Test Results] RHEL5 on x86_64 with gcc 4.1.2 20080704 (Red Hat 4.1.2-46)

...@gnu.org ... ## - ## ## Test results. ## ## - ## ERROR: 95 tests were run, 32 failed (25 expected failures). 2 tests were skipped. Full VERBOSE=1 results attached. Cheers, -- Gary V. Vaughan (g...@gnu.org) 2009-11-10.cd.nico.log.bz2

[2.2.7a Test Results] SLES 10 on x86_64 with gcc 4.1.2 20070115 (SUSE Linux)

...@gnu.org ... ## - ## ## Test results. ## ## - ## ERROR: 95 tests were run, 32 failed (25 expected failures). 2 tests were skipped. Full VERBOSE=1 results attached. Cheers, -- Gary V. Vaughan (g...@gnu.org) 2009-11-10.cd.isumi.log.bz2

[2.2.7a Test Results] SLES 10 on pentiumpro with gcc 4.1.2 20070115 (SUSE Linux)

Sorry again for the delay. I haven't begun to analyse any of this or the upcoming test results, and may not have the time to do so in any depth before the end of the year. I will, however, provide more details on request, apply proposed patches and rerun the testsuite in a timely fashio

Re: MinGW linux to win32 cross compiler and the test suite

ot;$progdir/$program" ${1+"$@"} My test suite works. Ie, I cross compile from Linux to win32 and the test suite gets run under wine. Personally, I find this an huge improvement over developing on windows. I now have a follow up question. Would it be possible/desirable to have autoconf/

Re: MinGW linux to win32 cross compiler and the test suite

Hi all, I have the beginnings of a solution to this issue. If I hack the libtool generated wrapper script and replace this: exec "$progdir/$program" ${1+"$@"} with WINEDLLPATH="$PATH;$WINEDLLPATH" exec wine "$progdir/$program" ${1

Re: MinGW linux to win32 cross compiler and the test suite

quoting. It backslashifies # metacharacters that are still active within double-quoted strings. Xsed='/bin/sed -e 1s/^X//' sed_quote_subst='s/\([\\`\\"$]\)/\\\1/g' # Be Bourne compatible (taken from Autoconf:_AS_BOURNE_COMPATIBLE). if test -n "${ZSH_VERSION+set}&quo

Re: MinGW linux to win32 cross compiler and the test suite

ine > to do two things; allow configure tests that need to run an > executable to work correctly, execute the test suite. > > The problem I'm having is that the wrapper scripts generated > by ltmain.sh in the tests/ directory cannot find the generated > DLL in the src/.lib/ direct

MinGW linux to win32 cross compiler and the test suite

xecute the test suite. The problem I'm having is that the wrapper scripts generated by ltmain.sh in the tests/ directory cannot find the generated DLL in the src/.lib/ directory. Is this a bug or am I doing something wrong? I'm using libtool version 1

Re: Libtool 2.1b test results

Ralf Wildenhues wrote: > Hi Peter, > > * Peter O'Gorman wrote on Wed, Feb 13, 2008 at 11:49:26PM CET: >> The dynamic linker checks are called for every tag, but produce no >> tagged variables. I was going to propose something like the attached >> patch at some point, but thought it best to wait 't

Re: Libtool 2.1b test results

Hi Peter, * Peter O'Gorman wrote on Wed, Feb 13, 2008 at 11:49:26PM CET: > > The dynamic linker checks are called for every tag, but produce no > tagged variables. I was going to propose something like the attached > patch at some point, but thought it best to wait 'til after 2.x is > released in

Re: Libtool 2.1b test results

On Wednesday 13 February 2008, Ralf Wildenhues wrote: > Argh. AC_LANG_PROGRAM does not produce a meaningful program for Java, > as Autoconf has no decent Java support. Gah! And we test for RUNPATH > using $OBJDUMP in each tag, GCJ last, so there it does not get set to &

Re: Libtool 2.1b test results

* Peter O'Gorman wrote on Wed, Feb 13, 2008 at 11:49:26PM CET: > Ralf Wildenhues wrote: > > Argh. AC_LANG_PROGRAM does not produce a meaningful program for Java, > > as Autoconf has no decent Java support. Gah! And we test for RUNPATH > > using $OBJDUMP in each tag,

Re: Libtool 2.1b test results

Ralf Wildenhues wrote: > Argh. AC_LANG_PROGRAM does not produce a meaningful program for Java, > as Autoconf has no decent Java support. Gah! And we test for RUNPATH > using $OBJDUMP in each tag, GCJ last, so there it does not get set to > yes, and shlibpath_overrides_runpath is

Re: Libtool 2.1b test results

Argh. AC_LANG_PROGRAM does not produce a meaningful program for Java, as Autoconf has no decent Java support. Gah! And we test for RUNPATH using $OBJDUMP in each tag, GCJ last, so there it does not get set to yes, and shlibpath_overrides_runpath is not a tagged variable. What a mess. Let&#

Re: Libtool 2.1b test results

* Ralf Wildenhues wrote on Sat, Feb 09, 2008 at 09:22:19AM CET: > * Mike Frysinger wrote on Sat, Feb 09, 2008 at 08:37:31AM CET: > > > # Whether or not to optimize for fast installation. > > fast_install=needless > > This looks very weird to me, and I cannot explain it at all. Did you use > any

libs with templates on unixware (was: CVS HEAD test 30)

* Tim Rice wrote on Mon, Feb 11, 2008 at 06:19:12AM CET: > > The thread started in libtool on Wed, 28 Sep 2005 > with the Subject: forward porting UnixWare fixes to HEAD > and on Fri, 11 Nov 2005 you moved it to libtool-patches, same subject. Thanks, this is it:

Re: CVS HEAD test 30

On Sun, 10 Feb 2008, Ralf Wildenhues wrote: > [ cutting libtool-patches ] > > Hi Tim, > > * Tim Rice wrote on Sun, Feb 10, 2008 at 12:05:33AM CET: > > Now only 54, 55 and of course 64 (because 54 & 55 fail) fail on > > UnixWare 7.1.4. There is still some work needed on templates on UnixWare > >

Re: CVS HEAD test 30

[ cutting libtool-patches ] Hi Tim, * Tim Rice wrote on Sun, Feb 10, 2008 at 12:05:33AM CET: > Now only 54, 55 and of course 64 (because 54 & 55 fail) fail on > UnixWare 7.1.4. There is still some work needed on templates on UnixWare > but nothing that should hold up this release. Was that becau

Re: CVS HEAD test 30

On Fri, 8 Feb 2008, Ralf Wildenhues wrote: > * Tim Rice wrote on Fri, Feb 08, 2008 at 03:00:05AM CET: > > I'm getting an "UNEXPECTED PASS" on test 30 of the new test suite > > on my UnixWare 7.1.4 box. > > Thanks for the bug report. I've installed

Re: Libtool 2.1b test results

* Mike Frysinger wrote on Sat, Feb 09, 2008 at 08:37:31AM CET: > On Saturday 09 February 2008, Ralf Wildenhues wrote: > > * Mike Frysinger wrote on Sat, Feb 09, 2008 at 05:38:19AM CET: > > > all of the tests pass with libtool-1.5.26 ... > > > > Do all of the old-style tests of 2.1b pass for you, to

Re: Libtool 2.1b test results

On Saturday 09 February 2008, Ralf Wildenhues wrote: > * Mike Frysinger wrote on Sat, Feb 09, 2008 at 05:38:19AM CET: > > all of the tests pass with libtool-1.5.26 ... > > Do all of the old-style tests of 2.1b pass for you, too? The Autotest > ones are all new. the ones that just say PASS/SKIP/FA

Re: Libtool 2.1b test results

Hi Mike, * Mike Frysinger wrote on Sat, Feb 09, 2008 at 05:38:19AM CET: > > are the tests supposed to pass ? because they dont for me :) Yes, they are. > all of the tests pass with libtool-1.5.26 ... Do all of the old-style tests of 2.1b pass for you, too? The Autotest ones are all new. > h

Libtool 2.1b test results

acularly well engineered release in the history of libtool, > or else it is the least well tested release ever... > > Either way, if there are no more bugs found before Feb 10th, I plan > to roll up 2.2 final. If you have any projects that you're thinking > of moving to libtool-2,

Re: CVS HEAD test 30

Hi Tim, * Tim Rice wrote on Fri, Feb 08, 2008 at 03:00:05AM CET: > > I'm getting an "UNEXPECTED PASS" on test 30 of the new test suite > on my UnixWare 7.1.4 box. > > A testlog generated with "gmake check-local TESTSUITEFLAGS='-d -x 30'"

CVS HEAD test 30

I'm getting an "UNEXPECTED PASS" on test 30 of the new test suite on my UnixWare 7.1.4 box. A testlog generated with "gmake check-local TESTSUITEFLAGS='-d -x 30'" is attached. I don't seem to understand the new test suite well

Re: Mac OS X 10.2.8 HEAD test failures.

> versions of automake and autoconf are too old to run the testsuite? > > For the tests for which it is ok that older autotools are insufficient, > we should just skip the individual test. I haven't had a chance to look > at the tests to see which ones should work and which one

Autoconf test version 2.61a released

We're happy to announce the release of Autoconf 2.61a. This is a test version, meant to shake out bugs in our switch from 'sed' to 'awk' to implement 'configure'-time substitutions, and (if 'printf' is available) from 'echo' to 'printf

Re: test failures

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo Ralf! On 7 Nov 2006, at 11:53, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Fri, Nov 03, 2006 at 11:50:11PM CET: On 27 Oct 2006, at 17:57, Ralf Wildenhues wrote: [...] + /* The ! is to invert C true to shell true [...] + return !(

Re: test failures

Hi Gary, * Gary V. Vaughan wrote on Fri, Nov 03, 2006 at 11:50:11PM CET: > On 27 Oct 2006, at 17:57, Ralf Wildenhues wrote: [...] > >+ /* The ! is to invert C true to shell true [...] > >+ return !( fabs (b (3.1415 / 2.)) < 0.01 && fabs (sqrt (four) - > >2.) < 0.01 ); > > } > > Rather than `!

Re: test failures

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo Ralf, On 27 Oct 2006, at 17:57, Ralf Wildenhues wrote: int main (void) { - return fabs (b (3.1415 / 2.)) < 0.01 && fabs (sqrt (4.) - 2.) < 0.01; + /* The ! is to invert C true to shell true + * The function b should call our sin (that

Re: test failures

On Sat, Oct 28, 2006 at 12:57:09AM +0200, Ralf Wildenhues wrote: > Hello Patrick, > > * Patrick Welche wrote on Fri, Oct 27, 2006 at 06:35:31PM CEST: > > > > (Spent the afternoon teaching reciprocal space in hexagonal crystals, so > > I'm quite sure sin(pi/2) =

Re: test failures

On Sat, 28 Oct 2006, Ralf Wildenhues wrote: (Spent the afternoon teaching reciprocal space in hexagonal crystals, so I'm quite sure sin(pi/2) = 1 :-) ) LOL. The test was written to prove you wrong. :-> I've checked in the patch below, to hopefully fix all the glitches I put

Re: test failures

Hello Patrick, * Patrick Welche wrote on Fri, Oct 27, 2006 at 06:35:31PM CEST: > > (Spent the afternoon teaching reciprocal space in hexagonal crystals, so > I'm quite sure sin(pi/2) = 1 :-) ) LOL. The test was written to prove you wrong. :-> I've checked in the patch b

Re: test failures

; > This one is different and will be treated later. Indeed - and your patch fixes all the other tests - thanks! Still staring at test 16, as the binary "main" looks fine from them "sees all libraries" point of view, NEEDED libb.so.0 NEEDED liba.so.0 N

Re: test failures

;ve applied the patch below. Cheers, Ralf 2006-10-26 Ralf Wildenhues <[EMAIL PROTECTED]> Assume presence of a config header in all files, to provoke test failures on all systems. * libltdl/lt__alloc.c: Likewise. * libltdl/libltdl/lt__dirent.h: Likewise.

test failures

All with CVS autotools, the following tests fail for me: 16: link-order2.at:25 Link order of deplibs. libtool 35: nonrecursive.at:70 compiling softlinked libltdl libtoolize automake autoconf 36: nonrecursive.at:94 compiling copied libltdl libtoolize automake autoconf 37

Autoconf test version 2.60b available

We're happy to announce the release of Autoconf 2.60b. This is a test version. It is mostly a bug-fix release since 2.60. We hope to generate Autoconf 2.61 soon, based on feedback from this test version. The important changes since Autoconf 2.60a are listed below. The sources and GPG det

Autoconf test version 2.60a available

We're happy to announce the release of Autoconf 2.60a. This is a test version. It is mostly a bug-fix release since 2.60. We hope to generate Autoconf 2.61 soon, based on feedback from this test version. The important changes since Autoconf 2.60 are listed below. The sources (1.4 MB) an

GNU Autoconf test version 2.59d available

GNU Autoconf test version 2.59d is now available. This is a beta release, intended to be largely identical to 2.60, to be released very soon, if no unexpected issues turn up. So test it now, use it with your code, and report any remaining issues, please! The important changes since 2.59c are

Re: Libtool 2.1a ported to SkyOS, how to test?

* Robert Szeleney wrote on Sun, Apr 23, 2006 at 05:22:05PM CEST: > > > >>/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. > >>-g -O2 -c -o ltdl.lo ltdl.c > >>mkdir .libs > >>rm: cannot remove directory `': Is a directory > Fixed. This was a kernel bug when trying to del

Re: Libtool 2.1a ported to SkyOS, how to test?

> OK, first thing here: compiling ltdl.lo has these spurious errors: /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c -o ltdl.lo ltdl.c mkdir .libs rm: cannot remove directory `': Is a directory gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c ltdl.c -DPIC -

Re: Libtool 2.1a ported to SkyOS, how to test?

Hi Robert, * Robert Szeleney wrote on Sun, Apr 23, 2006 at 11:52:44AM CEST: > > Ok, made progress. ./bootstrap for libtool-1.5.22 works now. (After > fixing the inital stack creation routine and tweaking gcc to return the > default library directory for 'gcc -print-search-dirs) Ah. Interestin

Re: Libtool 2.1a ported to SkyOS, how to test?

Hi! Ok, made progress. ./bootstrap for libtool-1.5.22 works now. (After fixing the inital stack creation routine and tweaking gcc to return the default library directory for 'gcc -print-search-dirs) But it looks like that there is a misconfiguration in the skyos specific settings I just adde

Re: Libtool 2.1a ported to SkyOS, how to test?

Hi Ralf! Erm. Did you mean 1.5 instead of 1.9? Because 1.9 is dead; branch-1-5 and HEAD are alive. Oh yes, sorry, I meant 1.5.22 Anyway, I have a suspicion why libtool 1.5.22 is not working. Looks like that the kernel can't setup the inital stack layout (with arguments and environment va

Re: Libtool 2.1a ported to SkyOS, how to test?

es). > The testsuite predicts that the 'shared' tests finished successfully. My > question is now, how can I test other packages, for instance libcairo, > with these modifications? > What is the prefered why to tell cairo that there is new libtool now? Probably either cairo

Libtool 2.1a ported to SkyOS, how to test?

make check. The testsuite predicts that the 'shared' tests finished successfully. My question is now, how can I test other packages, for instance libcairo, with these modifications? What is the prefered why to tell cairo that there is new libtool

GNU Autoconf test version 2.59c available

GNU Autoconf test version 2.59c is now available. This is an alpha release. We aim to generate the next Autoconf release soon, once the bugs are shaken out and things have stabilized enough. Of the list of changes since 2.59b below, please take special note of the GCS-related changes to the

Re: How does one compile in a "make check" test?

ssages :) > > How's this for an ugly hack? Ugly. ;-) > Add the following to a project build directory: > >test/cc.defs : >(echo COMPILE="'$(COMPILE)'" ; \ >echo LINK="'$(LINK)'" | sed 's/ -o.*//') >

Re: How does one compile in a "make check" test?

I like replying to my own messages :) How's this for an ugly hack? Add the following to a project build directory: test/cc.defs : (echo COMPILE="'$(COMPILE)'" ; \ echo LINK="'$(LINK)'" | sed 's/ -o.*//') > $@ an

How does one compile in a "make check" test?

Hi, I need to be able to create a source file and compile the thing in my "make check" testing. Unfortunately, I have no need for compiling anything in the "test" directory via "make", so the Makefile.am has no: mumble_PROGRAMS stuff in it. Consequently, the

  1   2   >