[Octave-bug-tracker] [bug #48363] __run-test_suite_ FAILs for data.cc-tst ('NaN' mismatches)

[Mike Miller]

Follow-up Comment #13, bug #48363 (project octave):

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):


$ sed -n '/checking.*frexp/,/ result:/p' config.log
configure:44942: checking whether frexp() can be used without linking with
libm
configure:44968: i686-w64-mingw32-gcc -o conftest.exe -g -O2 -pthread 
-I/scratch/jwe/mxe-octave/usr/i686-w64-mingw32/include
-Wl,-rpath-link,/scratch/jwe/mxe-octave/usr/i686-w64-mingw32/lib
-L/scratch/jwe/mxe-octave/usr/i686-w64-mingw32/lib conftest.c -lm   -lgdi32
-lws2_32 -luser32 -lkernel32 -lgdi32 -lws2_32 -luser32 -lkernel32 >&5
configure:44968: $? = 0
configure:44977: result: yes
configure:56034: checking whether frexp works
configure:56125: result: guessing no
configure:56181: checking whether frexpf can be used without linking with
libm
configure:56218: i686-w64-mingw32-gcc -o conftest.exe -g -O2 -pthread 
-I/scratch/jwe/mxe-octave/usr/i686-w64-mingw32/include
-Wl,-rpath-link,/scratch/jwe/mxe-octave/usr/i686-w64-mingw32/lib
-L/scratch/jwe/mxe-octave/usr/i686-w64-mingw32/lib conftest.c -lm   -lgdi32
-lws2_32 -luser32 -lkernel32 -lgdi32 -lws2_32 -luser32 -lkernel32 >&5
configure:56218: $? = 0
configure:56227: result: yes
configure:56296: checking whether frexpf works
configure:56364: result: guessing no


Next I would check liboctave to see whether it's linking with the system's
frexp and frexpf functions or the gnulib replacements.


$ cd D:\Octave\Octave-4.1.0+VEp_w64_20160711\lib\octave\4.1.0+
$ nm liboctave.dll.a | grep frexp
00000000 I __imp__rpl_frexpf
00000000 T _rpl_frexpf
00000000 I __imp__rpl_frexp
00000000 T _rpl_frexp


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)?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?48363>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/