Re: Testing 2.16 release candidate with gnulib

["Joseph S. Myers" <joseph at codesourcery dot com>]

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