Wed 13 Jul 2016 07:34:01 PM UTC, comment #19:
Yes, thank you.
Unfortunately we have no checks in place right now that bootstrap has been run. The build will either fail or it will produce unexpected results like this. I'm guessing that's what happened, the frexp functions in libgnu were not used and the system versions were used instead. In another case it might be a function from gnulib that doesn't exist on the system, and it will show up as a build error.
|
Wed 13 Jul 2016 06:59:21 PM UTC, comment #18:
OK you wanted to see this:
Now the frexp entries are found in config.log as well.
I still wonder why they didn't show up the first time, but most importantly the fix works.
Thanks!
In the mean time--run_test_suite__ is already hanging for several minutes in syscalls-cc.tst, but that must be another issue
|
Wed 13 Jul 2016 05:14:36 PM UTC, comment #17:
I'm even quite sure I ran ./bootstrap - it's in my bash history just before the ./dev/configure && make -j3 && make check command.
Nevertheless I'm happy to start all over again and let it build during preparing dinner... :-)
|
Wed 13 Jul 2016 05:08:50 PM UTC, comment #16:
Is there anyway to check (on Linux side) whether ./bootstrap has run?
I'm quite sure I did run it, but I try again, no problem.
|
Wed 13 Jul 2016 03:27:13 PM UTC, comment #15:
No, something's not right with this build, sorry. It's either not the changeset you thought it was or something wasn't bootstrapped or done right. (Unfortunately the hg id is not written to config.log, you'll have to do "__octave_config_info__ hg_id".)
If frexp and frexpf don't show up at all in config.log, then something was not included correctly.
|
Wed 13 Jul 2016 09:41:34 AM UTC, comment #14:
In that particular build by me (which I think is from after your cset from comment #11):
That config.log is attached (zipped).
Then:
In a 4.0.3 build (64-bit) I get:
Yesterday I've made a new build ("clean", i.e., w/o my usual personal patch collection). Tonight I'll try that one after installing it.
(file #37841)
|
Tue 12 Jul 2016 04:31:50 PM UTC, comment #13:
Ok, here's what I would check next.
The file D:\Octave\Octave-4.1.0+VEp_w64_20160711\share\octave\4.1.0+\etc\config.log should contain the full configuration of the build. Either share the whole file, or search for strings that look like this (pulled from the official 4.0.3 build):
Next I would check liboctave to see whether it's linking with the system's frexp and frexpf functions or the gnulib replacements.
The nm program should be in Octave's bin directory. This is the output I see for the library in the 4.0.3 release, should be the same in your build.
By the way, if you have a 4.0.x can you verify that this test did not fail there, that this only started failing on recent builds from default (corresponding to when the gnulib cleanup started)?
|
Tue 12 Jul 2016 01:37:50 PM UTC, comment #12:
Not fixed in a 64-bit (--enable-windows-64 configured) MXE cross-build from July 11 (not sure but hg id >= 67a44207da71)
|
Sat 09 Jul 2016 12:36:33 AM UTC, comment #11:
No test results on Windows, but pushed anyway, guess we'll find out eventually if this fixes it.
http://hg.savannah.gnu.org/hgweb/octave/rev/e0dbd81fd9b1
|
Tue 05 Jul 2016 03:51:55 PM UTC, comment #10:
I'll file a different bug report about the extra gnulib functions. I agree that it probably makes little difference, but I also don't like the untidyness of having chunks of code around that we aren't using.
|
Tue 05 Jul 2016 03:25:35 PM UTC, comment #9:
Re comment #7: Yes, my mistake, I copied existing files and missed the Copyright line.
Re comment #8: Maybe, but that's a lower priority issue. Having the modules around won't hurt anything, it will only make the configure process a little slower and compile a few extra objects that we may not link to.
|
Tue 05 Jul 2016 03:20:27 PM UTC, comment #8:
@Mike: I noticed your comment "since we have amassed quite a list of math functions in bootstrap.conf over the years, none of which we are using now". Should there be a separate bug report to prune bootstrap.conf before the 4.2 release?
|
Tue 05 Jul 2016 06:38:57 AM UTC, comment #7:
Mike, shouldn't you (not jwe) be listed in the copyright lines of the new files?
|
Sun 03 Jul 2016 04:58:37 PM UTC, comment #6:
Yes, we could add a wrapper, it would be something like the attached (needs testing on Windows, but should work).
I named the file "math-wrappers" with the expectation that we may need to do the same for other math functions from gnulib (since we have amassed quite a list of math functions in bootstrap.conf over the years, none of which we are using now).
(file #37689)
|
Sun 03 Jul 2016 03:07:58 PM UTC, comment #5:
I haven't been following jwe's changes closely, but he seems to have been placing wrappers around gnulib functions so they are called as straight 'C' functions, rather than having the C++ compiler use it's own choices. Maybe aske him if we can use that trick to access the gnulib replacement for frexp.
|
Sun 03 Jul 2016 04:31:15 AM UTC, comment #4:
The two-output-argument form is calling std::frexp, the single-return-value form is calling std::log2.
Ah, according to the gnulib manual section on frexp, this may have been fixed before when we were using gnulib, which we lost recently:
> This function does not work on infinite numbers on some
> platforms: IRIX 6.5, mingw, MSVC 9
(from https://www.gnu.org/software/gnulib/manual/html_node/frexp.html)
So this is exactly the type of bug that we were trying to fix by using gnulib, but GCC 6 has decided is bad to try to address (because they want std::frexp to only be able to call the system C library frexp function, not any replacement you may define).
|
Fri 01 Jul 2016 05:03:50 PM UTC, comment #3:
It is probably worth tracing this code down. It runs from Flog2 in data.cc in libinterp to liboctave/numeric/lo-mappers.cc. We are using C++ std::log2, but also std::log and std::frexp. Testing with a Windows VM shows there is a clear difference when different code paths are used.
This result is the same as Linux.
The two argument form, which is the failing one, is
|
Fri 01 Jul 2016 04:18:13 PM UTC, comment #2:
Should we just put a "if (! ispc () || isunix ())" and a comment around that assert if there is nothing we can do about it?
|
Fri 01 Jul 2016 03:39:19 PM UTC, comment #1:
Hasn't this always been the case? I believe it is the C lib implementation of log2 on Windows. Maybe try searching the bug reports or the the history of octave-maintainers on Nabble. I know its been discussed, I can't remember if there was any resolution.
|
Fri 01 Jul 2016 01:27:47 PM UTC, original submission:
|