On Thu, Jul 31, 2008 at 2:59 AM, Eric Blake <[EMAIL PROTECTED]> 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
