This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Testing 2.16 release candidate with gnulib
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Bruno Haible <bruno at clisp dot org>
- Cc: Carlos O'Donell <carlos_odonell at mentor dot com>, <libc-alpha at sourceware dot org>
- Date: Fri, 29 Jun 2012 23:25:58 +0000
- Subject: Re: Testing 2.16 release candidate with gnulib
- References: <4FEBDA04.6010709@mentor.com> <2058186.PDnk2TcgS3@linuix><4FEDC3FB.6050501@mentor.com> <70599729.sUypURCOaS@linuix>
On Sat, 30 Jun 2012, Bruno Haible wrote:
> [Carlos sent me the configuration results of testing a gnulib testdir
> with a glibc 2.16 release candidate on x86_64.]
These look like there was a problem in how the testing was done, so tests
did not actually run with the new library, but with an older system
library. Did the link lines actually include -rpath and -dynamic-linker
options with the directory names spelt exactly right? Do the tests (as
run with strace) really use the newly built libraries?
> * fma.o
> This is due to
> checking whether fma works... no
> The test program exited with status 108 = 4 | 8 | 32 | 64
> which means that the following test program will show them:
Passes for me on x86_64.
> * fmaf.o
> This is due to
> checking whether fmaf works... no
> The test program exited with status 108 = 4 | 8 | 32 | 64
> which means that the following test program will show them:
Passes for me on x86_64.
> * fmal.o
> This is due to
> checking whether fmal works... no
> The test program exited with status 58 = 2 | 8 | 16 | 32
> which means that the following test program will show them:
Passes for me on x86_64.
The fnmatch, logb, logbf tests all pass for me as well. logf is present
in libm.so - if it weren't, glibc's own libm tests would fall over.
> This is because when Ulrich fixed
> <http://sourceware.org/bugzilla/show_bug.cgi?id=12782>
> he introduced another bug. See comment 3 in that bugzilla.
Comments in closed bugs are no good as a way of reporting an issue unless
you reopen the bug when commenting. Please file a new bug (well, three
bugs, one for each of the three issues listed). (I generally advise
opening a new bug rather than reopening the previous one, to avoid
confusion exactly what the previous bug was about.) It's established as
good glibc practice that a developer discovering a well-defined issue they
aren't immediately planning to fix themselves should file a bug for it.
--
Joseph S. Myers
joseph@codesourcery.com