[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FAIL: test-strtod
Re: FAIL: test-strtod
Thu, 31 Jul 2008 03:42:26 +0000
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.
> 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
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.
> 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