Release candidate available

>> figure()
>> for ii=1:9 hax(ii) = subplot(3,3,ii); endfor
>> get(hax(4), 'position')
ans =

   0.1300   0.4421   0.1576   0.1508

>> hax_new = subplot (2,1,1);
>> get(hax_new, 'position')
ans =

   0.1300   0.6248   0.7750   0.3002

>>

the problem in 6.2. I have not tried anything older.

Hu. It looks like it claims that the axes are smaller for you than they are for me.
Is the figure the same size?
For me:

>> close all
>> hf = figure;
>> get(hf, 'position')
ans =

   300   204   560   416

Anyway, since this is not a regression, I don’t think it should block the release.
Should we move that to a bug report on savannah?

Slightly off. I wonder if this is due to hi-res display scaling.

>> hf = figure()
hf = 1
>> get(hf, 'position')
ans =

   300   207   560   413

>>

Does it have to do with the height of the button bar (which seems to be different for you and for me)?
I also noticed that the figure position doesn’t match the default position for me:

>> get(groot, 'defaultfigureposition')
ans =

   300   200   560   420

Not sure where the 4 pixels difference comes from.
Definitely deserves a bug report if we don’t have one yet.

this is the same:

>> get(groot, 'defaultfigureposition')
ans =

   300   200   560   420

>>

It’s def something to do with high-resolution display.
I’ve changed scaling (from 200% to 150% to 100%) – no change, test is failing.
Then I was reducing the resolution from its natural (3840x2160) down;
it was still failing at 2014x1536, but passed at 2048x1152 and below.
I will fill a bug report shortly.

p.s. Done: GNU Octave - Bugs: bug #60759, test subplot fails on hi-res... [Savannah]

@dasergatskov: Thanks for opening the report. Since this isn’t a (recent?) regression, I don’t think it should block the release.

Imho, we shouldn’t change the (default) number of used OpenBLAS threads between minor releases. So, that change shouldn’t block the release either.
(Also, we probably shouldn’t override OPENBLAS_NUM_THREADS in the startup script if it was set by the user. Additionally: What about the batch script? Would that need to be adapted, too?)

I believe those are the only issues identified in this thread (so far).

@jwe: Would you mind creating another release candidate? We’ve seen in the past that the binaries depended on the hardware that built them. That shouldn’t be happening any more. Anyway, it would be good to check if updating to the newer OpenBLAS version really resolved the issue Dmitiri was seeing on his laptop. Equally important: That update might have introduced regressions.

Hi,

While building on macos 11.4 with clang I see the following warning a few times.
I’m not sure whether it is anything dangerous though …

c.

In file included from /Users/carlo/Documents/_Programmi/Miei/C/octave//octave-6.2.90/libinterp/corefcn/interpreter.cc:32:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/set:429:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__tree:15:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/memory:2084:5: warning: delete called on non-final 'octave::push_parser' that has virtual functions but non-virtual destructor [-Wdelete-non-abstract-non-virtual-dtor]
    delete __ptr;
    ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/memory:2345:7: note: in instantiation of member function 'std::__1::default_delete<octave::push_parser>::operator()' requested here
      __ptr_.second()(__tmp);
      ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/memory:2299:19: note: in instantiation of member function 'std::__1::unique_ptr<octave::push_parser, std::__1::default_delete<octave::push_parser>>::reset' requested here
  ~unique_ptr() { reset(); }
                  ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/memory:3645:21: note: in instantiation of member function 'std::__1::unique_ptr<octave::push_parser, std::__1::default_delete<octave::push_parser>>::~unique_ptr' requested here
    unique_ptr<_Yp> __hold(__p);
                    ^
/Users/carlo/Documents/_Programmi/Miei/C/octave//octave-6.2.90/libinterp/corefcn/interpreter.cc:1239:27: note: in instantiation of function template specialization 'std::__1::shared_ptr<octave::base_parser>::shared_ptr<octave::push_parser>' requested here
            repl_parser = std::shared_ptr<base_parser> (pp);
                          ^

make check retturns

Summary:

  PASS                            16094
  FAIL                                6
  REGRESSION                          1
  XFAIL (reported bug)               44
  SKIP (missing feature)             37
  SKIP (run-time condition)          31

The failed tests are

>>>>> processing /Users/carlo/Documents/_Programmi/Miei/C/octave/octave-6.2.90/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.90/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
>>>>> processing /Users/carlo/Documents/_Programmi/Miei/C/octave/build-release/libinterp/corefcn/mappers.cc-tst
***** test
 rval = pi/2;
 ival = 1.31695789692481635;
 obs = asin ([2, 2-i*eps, 2+i*eps]);
 exp = [rval - ival*i, rval - ival*i, rval + ival*i];
 assert (obs, exp, 2*eps);
 obs = asin ([-2, -2-i*eps, -2+i*eps]);
 exp = [-rval + ival*i, -rval - ival*i, -rval + ival*i];
 assert (obs, exp, 2*eps);
 assert (asin ([2 0]),  [rval - ival*i, 0], 2*eps);
 assert (asin ([2 0i]), [rval - ival*i, 0], 2*eps);
!!!!! test failed
ASSERT errors for:  assert (obs,exp,2 * eps)

  Location  |  Observed  |  Expected  |  Reason
    (3)      1.5708+1.317i 1.5708+1.317i   Abs err 1.1102e-15 exceeds tol 4.4409e-16 by 7e-16
shared variables   scalar structure containing the fields:

    rt2 = 1.4142
    rt3 = 1.7321
>>>>> processing /Users/carlo/Documents/_Programmi/Miei/C/octave/octave-6.2.90/scripts/general/logspace.m
***** assert (logspace (Inf + 1i, Inf + 1i, 3), repmat (complex (-Inf,Inf), [1, 3]))
!!!!! test failed
ASSERT errors for:  assert (logspace (Inf + 1i, Inf + 1i, 3),repmat (complex (-Inf, Inf), [1, 3]))

  Location  |  Observed  |  Expected  |  Reason
    (1)        Inf+NaNi    -Inf+Infi     'NaN' mismatch
    (2)        Inf+NaNi    -Inf+Infi     'NaN' mismatch
    (3)        Inf+NaNi    -Inf+Infi     'NaN' mismatch
***** assert (logspace (-Inf + 1i, Inf + 1i, 3), [0, NaN + NaN * 1i, complex(-Inf, Inf)])
!!!!! test failed
ASSERT errors for:  assert (logspace (-Inf + 1i, Inf + 1i, 3),[0, NaN + NaN * 1i, complex(-Inf, Inf)])

  Location  |  Observed  |  Expected  |  Reason
    (3)        Inf+NaNi    -Inf+Infi     'NaN' mismatch
>>>>> processing /Users/carlo/Documents/_Programmi/Miei/C/octave/octave-6.2.90/scripts/specfun/expint.m
***** test <*47738>
 assert (expint (10i), 0.0454564330044554 + 0.0875512674239774i, -4*eps);
!!!!! regression: https://octave.org/testfailure/?47738
ASSERT errors for:  assert (expint (10i),0.0454564330044554 + 0.0875512674239774i,-4 * eps)

  Location  |  Observed  |  Expected  |  Reason
     ()      0.045456+0.087551i 0.045456+0.087551i   Rel err 9.1442e-16 exceeds tol 8.8818e-16 by 3e-17

I pushed the following changeset to declare the base_parser destructor virtual:

http://hg.savannah.gnu.org/hgweb/octave/rev/e04b4706ca18

Wrt the first failing tests that involve .mex files: I believe Octave needs to be installed on macOS before it can compile .mex files. Do those tests still fail if you run make install before make check?

Most of the other tests look like differences in the precision of some functions of the math libraries on macOS. IIRC, we relaxed some of those tolerances in the past or duplicated the tests that were failing on some platforms. Maybe we could do something similar for the tests here.

The Inf-NaN mismatch is probably something similar. IIRC, there is already an open bug report about that. It would be interesting to know what Matlab does for those tests on macOS.

The bug_51725 and bug_54096 functions are defined as MEX files and as far as I can tell, the check target depends on the MEX files and they should be compiled when you run make check.

@mmuetzel: I can make another test release in the next day or so.

I tried the following to see whether building the mex files work :

$ make test/mex/bug_54096.mex
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'
ld: warning: directory not found for option '-L/opt/octave/6.2.90/lib/octave/6.2.90'
ld: warning: directory not found for option '-L/opt/octave/6.2.90/lib'
ld: file not found: /opt/octave/6.2.90/bin/octave-6.2.90
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Indeed, it seems building the mex files depends on the octave libraries being installed …

Here is some more verboseoutput :

$ make V=1 test/mex/bug_54096.mex 
preserving existing HG-ID file
./src/mkoctfile --mex -I/Users/carlo/Documents/_Programmi/Miei/C/octave//octave-6.2.90/libinterp/corefcn -Ilibinterp/corefcn -L./libinterp/.lib -L./liboctave/.lib -v /Users/carlo/Documents/_Programmi/Miei/C/octave//octave-6.2.90/test/mex/bug_54096.c -o test/mex/bug_54096.mex || rm -f test/mex/bug_54096.mex
clang -c -O3 -g -I/opt/local/include -I/opt/local/libexec/qt5/include -fPIC -I/opt/octave/6.2.90/include/octave-6.2.90/octave/.. -I/opt/octave/6.2.90/include/octave-6.2.90/octave -I/opt/octave/6.2.90/include  -D_THREAD_SAFE -pthread -O3 -g   -I. -I/Users/carlo/Documents/_Programmi/Miei/C/octave//octave-6.2.90/libinterp/corefcn -Ilibinterp/corefcn  -DMEX_DEBUG /Users/carlo/Documents/_Programmi/Miei/C/octave//octave-6.2.90/test/mex/bug_54096.c -o /var/folders/k4/bw2p0ldj7nsb4s38g347lbhc0000gn/T//oct-heWVRw.o
clang++ -std=gnu++11 -I/opt/octave/6.2.90/include/octave-6.2.90/octave/.. -I/opt/octave/6.2.90/include/octave-6.2.90/octave -I/opt/octave/6.2.90/include  -D_THREAD_SAFE -pthread -mmacosx-version-min=11.1 -O3 -g  -o test/mex/bug_54096.mex  /var/folders/k4/bw2p0ldj7nsb4s38g347lbhc0000gn/T//oct-heWVRw.o  -L./libinterp/.lib -L./liboctave/.lib -bundle -bundle_loader /opt/octave/6.2.90/bin/octave-6.2.90 -mmacosx-version-min=11.1 -O3 -L/opt/local/lib -L/opt/local/libexec/qt5/lib -Wl,-rpath -Wl,/opt/sundials/5.1.0/lib  -L/opt/octave/6.2.90/lib/octave/6.2.90 -L/opt/octave/6.2.90/lib  -mmacosx-version-min=11.1 -O3 -L/opt/local/lib -L/opt/local/libexec/qt5/lib -Wl,-rpath -Wl,/opt/sundials/5.1.0/lib -loctinterp -loctave
ld: warning: directory not found for option '-L./libinterp/.lib'
ld: warning: directory not found for option '-L./liboctave/.lib'
ld: warning: directory not found for option '-L/opt/octave/6.2.90/lib/octave/6.2.90'
ld: warning: directory not found for option '-L/opt/octave/6.2.90/lib'
ld: file not found: /opt/octave/6.2.90/bin/octave-6.2.90
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Can you try adding V=1 to the make command?

make V=1 test/mex/bug_54096.mex

to find the link command that is executed? Is there a way we can modify that command so that it works on MacOS systems when Octave is not installed?

[edited] OH! Sorry, I missed the more verbose output you already provided…

I don’t understand all those options, like -bundle and -bundle-loader. Where are those options coming from? Is it something we add in Octave’s configure script or Makefiles or is it something that is generated by libtool?

What is necessary to build a dynamically loadable file that can be opened with dlopen and that can refer to symbols in the program that loads it? That is what we need for both .mex and .oct files. What do we do to create .oct files that can be loaded in the build tree before Octave is installed? How is that different from what we are doing here for .mex files?

I would drop optimization level to O2. Apple’s clang is based on an early snapshot of clang-12 that had some bugs in O3 optimization. E.g. AMD’s compiler (which is also based on clang-12 snapshot) miscompiles octave at O3 level.

IIUC, those are flags we are adding in our configure script here:
m4/acinclude.m4 (line 3529)
I’m not a macOS expert at all, so I could be completely wrong. As I understand it, those switches are used on macOS to produce relocatable libraries. The path after -bundle -bundle-loader must point to a binary that exports the necessary symbols at link time. IIUC, that does not need to be the same that is used on execution.

@apjanke’s change octave: b4cb9d04f3cf (gnu.org) (not yet on stable afaict) might also be relevant here.

@mmuetzel, those changes may be helpful. I realize now that we are using mkoctfile to build these .mex files and we use some other rules to build the .oct files in the dldfcn directory. I’m not sure whether it would be better change the rules for the .mex files to be like the ones for the dldfcn .oct files or to fix mkoctfile to work properly in the build tree.

What would be the changes that would be needed for mkoctfile to work properly in the build tree?
Would those have any additional benefit (like relocatability of libraries and/or binaries)? I’m not saying that this would be a necessary feature that we’d definitely need. But it might be a positive side effect of such a change.
If the changes would purely be for that special case (calling mkoctfile from the build tree), I’d guess that it might be easier to maintain if the build rule for .mex files would be changed to be more similar to how we build .oct files in the build tree (and we don’t introduce additional complexity in the code for mkoctfile).

1 Like

It might be good to use mkoctfile to build the .oct files in the build tree as well. I’m imagining just having to override some options for where to find the header files and dependency libraries instead of what would be used when mkoctfile is installed.

It would also be great if we could extract from libtool whatever the system-dependent rules are for building DLLs/dynamic modules/shared libraries so that we don’t have to duplicate (poorly, most likely) some of that logic for use in mkoctfile. But it doesn’t seem easy to do that. We could just use libtool, but that doesn’t work so well on Windows systems.