MSYS2 seems to build libtool for Windows:
MINGW-packages/mingw-w64-libtool at master · msys2/MINGW-packages (github.com)
So we could probably do the same in MXE Octave as well if that would help…
Or we could just install the MSYS2 libtool (like we do e.g. for bash, python and a lot of other packages).
But maybe I’m not understanding correctly. Is the issue that libtool is (currently) not available for us on Windows? Or is it difficult to use on Windows for other reasons?
The way we use it, I think libtool is a Unix shell script generated by the configure script. That doesn’t make it impossible to use on Windows but it’s not convenient as it requires Unix shell utilities. I know, we provide those, but we also made mkoctfile an .exe program on Windows to avoid having to execute a shell script.
Afaict, the MSYS2 shell that we install as part of Octave on Windows is a bash. So in principle, it should be possible to run shell scripts on that platform.
Edit: As a preliminary test, I tried to run libtool from a cmd shell with the following command:
C:\msys64\usr\bin\sh --login -eo pipefail -c "libtool --help"
That seems to work here (with the shell and libtool script installed by MSYS2).
While this is somewhat awkward, I’d guess it should also work with the bash we install as part of Octave on Windows.
I pushed a patch here that relaxes the tolerance for two of the failing tests on macOS:
octave: c8585732ce08 (gnu.org)
And grafted a change from default to stable that marks the Inf-NaN mismatch as a known error on that platform:
octave: 10292fb30c8f (gnu.org)
I don’t think that the inability to compile .mex files before installing Octave on macOS should block the release. In the end, it’s not a regression afaict.
Is there going to be a new release candidate?
c.
Yes. Sorry for the delay, I will make one.
I’m uploading the 6.2.92 sources to alpha.gnu.org now. I’ll upload the Windows binaries when they are done building.
The Windows binary files for the 6.2.92 release candidate are on alpha.gnu.org now.
Thanks.
__run_test_suite__ is passing without unknown fails with the 64-bit installer on Windows 10 for me.
jwe
June 22
The Windows binary files for the 6.2.92 release candidate are on alpha.gnu.org now.Visit Topic or reply to this email to respond.
On macos 11.4 building with Apple clang version 12.0.5 and gfortran 10.3
I get now
Summary:
PASS 16102
FAIL 3
REGRESSION 1
XFAIL (reported bug) 46
SKIP (missing feature) 37
SKIP (run-time condition) 33
the regression is
>>>>> processing /Users/carlo/Documents/_Programmi/Miei/C/octave/octave-6.2.92/scripts/linear-algebra/logm.m
***** test <*60738>
A = [0.2510, 1.2808, -1.2252; ...
0.2015, 1.0766, 0.5630; ...
-1.9769, -1.0922, -0.5831];
warning ("off", "Octave:logm:non-principal", "local");
assert (expm (logm (A)), A, 40*eps);
!!!!! regression: https://octave.org/testfailure/?60738
ASSERT errors for: assert (expm (logm (A)),A,40 * eps)
Location | Observed | Expected | Reason
(3,1) -1.9769-2.2204e-16i -1.9769 Abs err 1.2881e-14 exceeds tol 8.8818e-15 by 4e-15
(1,2) 1.2808+1.5543e-15i 1.2808 Abs err 1.2311e-14 exceeds tol 8.8818e-15 by 3e-15
(2,2) 1.0766+0i 1.0766 Abs err 1.2879e-14 exceeds tol 8.8818e-15 by 4e-15
(3,2) -1.0922+1.6098e-15i -1.0922 Abs err 1.056e-14 exceeds tol 8.8818e-15 by 2e-15
while the unexpected FAIL are
>>>>> processing /Users/carlo/Documents/_Programmi/Miei/C/octave/octave-6.2.92/test/mex/bug-51725.tst
***** assert (bug_51725 (), [])
!!!!! test failed
'bug_51725' undefined near line 2, column 2
***** error <element number 2 undefined in return list> [x,y,z] = bug_51725 ();
!!!!! error failed.
Expected <element number 2 undefined in return list>, but got <'bug_51725' undefined near line 2, column 2>
>>>>> processing /Users/carlo/Documents/_Programmi/Miei/C/octave/octave-6.2.92/test/mex/bug-54096.tst
***** test
s = bug_54096 ();
assert (s, struct ("field", []));
assert (s.field, []);
!!!!! test failed
'bug_54096' undefined near line 3, column 3
which seem to be the due to the known issue with MEX
c.
@cdf: The regression is from a test that was newly added after the last release candidate.
Could you please show what you see for the following?
A = [0.2510, 1.2808, -1.2252; ...
0.2015, 1.0766, 0.5630; ...
-1.9769, -1.0922, -0.5831];
[u, s] = schur (A);
[u, s] = rsf2csf (u, s);
format long
u
s
eigv = diag (s);
tol = rows (A) * eps (max (abs (eigv)));
real_neg_eigv = (real (eigv) < -tol) & (imag (eigv) <= tol)
One element of real_neg_eigv should be true, the others false.
Either that might be wrong. Or it might be another case where we would need to relax the tolerance on macOS.
Which BLAS/LAPACK libraries are you using?
Do you see which is the third failing test?
There might be a new failing test for the stk package (on Windows 10, 64-bit). At least, I couldn’t find a bug report:
>> pkg load stk
>> test stk_param_init
***** test % check equivariance of parameter estimates
f = @(x) sin (x);
xi = stk_sampling_regulargrid (10, 1); zi = stk_feval (f, xi);
shift = 1000; scale = 0.01;
model = stk_model ('stk_materncov32_iso');
p1 = stk_param_init (model, xi, zi);
p2 = stk_param_init (model, xi, shift + scale .* zi);
assert (stk_isequal_tolabs (p2(1), p1(1) + log (scale^2), 1e-10))
assert (stk_isequal_tolabs (p2(2), p1(2), eps))
!!!!! test failed
assert (stk_isequal_tolabs (p2 (1), p1 (1) + log (scale ^ 2), 1e-10)) failed
The tolerance in the assertation seems to be exceeded:
>> p1(1) + log (scale^2) - p2(1)
ans = -1.4794e-10
The same test still passed with the previous release candidate 6.0.90.
I don’t know if this points to a deeper issue. Afaict, the stk package wasn’t updated recently.
Maybe the OpenBLAS update?
Edit: I didn’t notice any other new failing tests while running pkg test ... for all pre-installed packages.
Just downloaded, built, and ran make check on Kubuntu 18.04. No failures.
>> A = [0.2510, 1.2808, -1.2252; ...
0.2015, 1.0766, 0.5630; ...
-1.9769, -1.0922, -0.5831];
[u, s] = schur (A);
[u, s] = rsf2csf (u, s);
format long
u
s
eigv = diag (s);
tol = rows (A) * eps (max (abs (eigv)));
real_neg_eigv = (real (eigv) < -tol) & (imag (eigv) <= tol)
u =
Column 1:
0.589847463097695 + 0i
-0.194721954523054 + 0i
0.783685734656396 + 0i
Column 2:
-0.728486793729987 + 0.077814272007087i
0.132466928851119 + 0.327674935558408i
0.581215513227468 + 0.022849660485176i
Column 3:
0.216987863189139 - 0.261243503151440i
0.913733204122014 + 0.047504120654802i
0.063717090392160 + 0.208430376594836i
s =
Column 1:
-1.799651595756385 + 0i
0 + 0i
0 + 0i
Column 2:
0.258925082727598 - 0.243160188453671i
1.272075797878193 - 0.625493567993862i
0 + 0i
Column 3:
-0.678060827972855 + 0.092853427471474i
-1.519902064099683 + 0.000000000000000i
1.272075797878193 + 0.625493567993862i
real_neg_eigv =
1
0
0
I am using openblas from macports.
wasn’t that 3 failing tests in the output I posted above?
IIUC there are 2 failing tests (one assertion and one check for
an error message) in bug_51725 and one in
bug_54096, is this not the case?
c.
Thanks.
So the new test seems to be ok. It’s just the accuracy that seems to be slightly lower on macOS (more or less consistently).
I pushed a change to stable that relaxes the tolerance in that test on that platform:
octave: 20380c9bed30 (gnu.org)
You are right. I didn’t notice that there were two failing tests for the same file.
Would it be possible for you to check if the tests involving .mex files would pass after you installed the release candidate?
I just installed and launched make check it’s still running but I suspect the mex tests will still fail because I see the following near the beginning of the output
/Applications/Xcode.app/Contents/Developer/usr/bin/make check-local
preserving existing HG-ID file
MKMEXFILE test/mex/bug_54096.mex
ld: warning: directory not found for option '-L./libinterp/.lib'
ld: warning: directory not found for option '-L./liboctave/.lib'
MKMEXFILE test/mex/bug_51725.mex
ld: warning: directory not found for option '-L./libinterp/.lib'
ld: warning: directory not found for option '-L./liboctave/.lib'
It’s just warnings though so I’ll report back when the tests are finished.
[EDIT] BTW: why are we trying to direct the linker to '-L./libinterp/.lib'?
the directories created by libtool are named '-L./libinterp/.libs' with the final ‘s’
c.
I stand corrected :
Summary:
PASS 16105
FAIL 0
REGRESSION 1
XFAIL (reported bug) 46
SKIP (missing feature) 37
SKIP (run-time condition) 33
c.
Good point. That looks like a typo in that file (lines 35 and 45) to me:
octave: f4ccc941a941 test/mex/module.mk (gnu.org)
Or is this dependent on the used version of libtool? But if I correctly understood what @jwe wrote earlier, we are using “our” version of libtool anyway…
I just filed a bug about a hard crash with the release candidate:
GNU Octave - Bugs: bug #60813, GUI crashes when quitting debug… [Savannah]
I am also not sure about this line :
https://hg.savannah.gnu.org/hgweb/octave/file/stable/m4/acinclude.m4#l3526
I never see any executable in libinterp/octave so what is this intended for?
when/where is it used?
c.