Re: FAIL: test-strtod

[Dennis Clarke]

On Thu, Jul 31, 2008 at 2:59 AM, Eric Blake <address@hidden> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> According to Dennis Clarke on 7/30/2008 9:17 AM:
> |> Somehow, the test needs to be made more robust; we either need more m4
> |> magic to determine if -lm is necessary for fabs, or a gnulib replacement
> |> for fabs that works without requiring libm, or a way to rewrite that test
> |> to not need fabs.  In the meantime, feel free to manually add -lm to the
> |> link line for that particular test program.
> |
> | did that ... but don't know what to do with it.
>
> Great - you compiled it.  Now run it.  If test-strtod exits with 0 status
> and no error messages, then we've solved the link error.

linked and ran .. looks good.

bash-3.2$ pwd
/export/home/dclarke/build/m4-1.5.89a.31-d9538d
bash-3.2$ tests/test-strtod

>  If it still
> complains of any assertion failures, then look at which lines it is
> complaining about, and report it both back here and to Sun.  And if you'd
> like, I can build another m4 snapshot using today's gnulib patch.

looks like a minor link error in a Makefile.

> |
> | In reality I need a stable release grade package and 1.5.89a.31-d9538d
> | is not it. I'll go back to looking at m4-1.4.11 and see what there is
> | that I can do to get it to pass its testsuite on Solaris 10.  Perhaps
> | gl_cv_func_strtod_works=no is the only way to go.
> |
> | Which feels like a hack somehow.
>
> What's wrong with working around the configure bug?  You're not even
> hacking m4 itself, just the associated gnulib code that tries to
> stress-test gnulib replacement functions for platforms that need them.

doing something like this :

./configure --enable-threads=posix --disable-nls --prefix=/somepath
gl_cv_func_strtod_works=no

is perfectly fine for me personally but can I ship that out the door
to production servers?

I'd rather just run the whole testsuite as provided and get a clean
report and then we *know* that we can trust the result.

> Also, you may be interested in running 'make -k check' to see whether the
> rest of the testsuite, beyond the gnulib tests, passes (and depending on
> whether you get a working C99 compiler environment, whether or not you
> skip test-strtod, you might also see the checks/157.format test fail).

mmmkay .. looks like I have some work to do tonight :-)

> Since the only use of strtod(3) in m4 is parsing arguments to the format
> builtin, which itself is a GNU extension, you won't be compromising
> anything, even if you install m4 without figuring out how to hack around
> the bugs in the m4 1.4.11 tarball in relation to strtod handling.

seems totally reasonable to me. I like it.

> | Maybe I need to think about this and see what the *real* issue is with
> | libc and then see if that can be fixed. Not a small task.
>
> Until you run test-strtod, as compiled with -lm and a C99 compiler

which I did. See above.  looks good.

> we
> don't know whether there really is a C99 bug, or just a testsuite bug.
> But more than likely, it is just a testsuite bug, and by reporting it, we
> have already fixed it for the next m4 release.

I'm very happy to be of service and hopefully you don't mind telling
me to do obvious things. I'm not a code shark but can generally figure
out most things if given some time and a beating with a sharp stick.

The only changes needed are a tweak or two to the Makefiles I think.
Manual intervention to link something is no great hardship. Now then .
.shall I go for a total top to bottom build and test with
m4-1.5.89a.31-d9538d once again and then see if everything passes
smoothly?

Dennis