octave 10.1.0

[BrewTestBot]

Created by brew bump

---

Created with brew bump-formula-pr.

[daeho-ro]

It seems that dynare is not working with octave 10.

[mmuetzel]

It seems that dynare is not working with octave 10.

Compatibility of Dynare with Octave 10 seems to have been fixed upstream with this change: https://git.dynare.org/Dynare/dynare/-/commit/e3ff2f108862b462bfb8f5b92bcebaaf6f8a6aa9

Maybe, you could cherry-pick that patch here...

[mmuetzel]

Some background to the change in Octave 10: .mex file linking has changed. .mex files need to be linked with -loctmex instead of with -loctinterp -loctave. We expect that liboctmex will change far less often than liboctinterp or liboctave. We hope that the soversion of liboctmex won't change on minor or major(!) version updates of Octave looking forward. So, dependencies that only need to link to liboctmex (like Dynare iiuc) might no longer need to be rebuilt on each update of Octave.

[mmuetzel]

https://github.com/Homebrew/homebrew-core/pull/218368/files#diff-031e5a5adbc75659239d3bc9de4ac2114b3bd6c53cef704b992552956aee683aR86-R91

    # Default configuration passes all linker flags to mkoctfile, to be
    # inserted into every oct/mex build. This is unnecessary and can cause
    # cause linking problems.
    inreplace "src/mkoctfile.in.cc",
              /%OCTAVE_CONF_OCT(AVE)?_LINK_(DEPS|OPTS)%/,
              '""'

The build rules on macOS have been slightly overhauled for Octave 10. You should no longer need the above modification of the source files. By default, Octave should no longer link mex or oct files to all dependencies.

[mmuetzel]

While at it, maybe you could also consider using the patch I proposed in another issue: https://github.com/Homebrew/homebrew-core/issues/201376#issuecomment-2757391901

[mmuetzel]

Another potential caveat for the update: Newer versions of gnulib no longer accept Apple's version of iconv: see https://savannah.gnu.org/bugs/?66448

It might be better to depend on the version of iconv that is distributed by Homebrew. Otherwise, some text encoding conversion facilities in Octave might no longer work on macOS 14 or newer.

[mmuetzel]

The build error looks like Octave fails to compile some sources from the statistics package. The dynare.rb hard-codes the version 1.6.5 of that package: https://github.com/Homebrew/homebrew-core/blob/c5beefebbf5c629131626d22e67d7c1b7904315b/Formula/d/dynare.rb#L85 Newer versions of the statistics package are available now: https://github.com/gnu-octave/statistics/releases/tag/release-1.7.3

Could you please try if updating to the latest statistics package avoids that compilation error?

[mmuetzel]

By the way: Is it possible to have a look at the output of the configure script in the CI run?

[mmuetzel]

Still the same build error.

I'm suspecting that something is setting the environment variable CXX. And with that, the compiler flags that mkoctfile would use by default are overridden.

Could you please try to add CXX+=" -std=gnu++17" to the test step in dynare.rb (or whatever Ruby syntax would add that to that environment variable)? Alternatively, the equivalent of unset CXX might also help...

[mmuetzel]

A potential implementation of that idea in Octave syntax could be the following code snippet change in dynare.rb (note the additional unsetenv command):

    # Replace `makeinfo` with dummy command `true` to prevent generating docs
    # that are not useful to the test.
    (testpath/"dyn_test.m").write <<~MATLAB
      makeinfo_program true
      unsetenv ('CXX');
      pkg prefix #{testpath}/octave
      pkg install statistics-release-#{statistics.version}.tar.gz
      dynare bkk.mod console
    MATLAB

[mmuetzel]

It looks like this is finally building and passing the tests now. 🎉

I still suspect that executing __run_test_suite__ in Octave on macOS 14 or later will fail a couple of tests. That is because gnulib no longer accepts Apple's own iconv implementation. (See https://github.com/Homebrew/homebrew-core/pull/218368#issuecomment-2789274652)

Would it be possible to use Homebrew's iconv as dependency of Octave instead? At least on macOS 14 and newer?

[daeho-ro]

@mmuetzel Thank you for the huge help and now it seems fine.

I am not confident to change iconv and it is fine as-is, maybe we can handle it later once something happen.

[mmuetzel]

@mmuetzel Thank you for the huge help and now it seems fine.

Thank you for taking this on.

I am not confident to change iconv and it is fine as-is, maybe we can handle it later once something happen.

Ok. It might be okay to leave that for a later day.

Would it be ok to attempt to address #201376 as part of the update though? I'm afraid that if this isn't addressed with the major version update now, it won't be addressed for the foreseeable future again.

[mmuetzel]

Looking at octave.rb, you are already appending to one of the startup files here: https://github.com/Homebrew/homebrew-core/blob/ad647016390045dfbef9a1e54e87e612e9786194/Formula/o/octave.rb#L136-L138

Maybe, you could expand that to something like this to address #201376:

    # Make sure that Octave uses the modern texinfo at run time
    rcfile = buildpath/"scripts/startup/site-rcfile"
    rcfile.append_lines "makeinfo_program(\"#{Formula["texinfo"].opt_bin}/makeinfo\");" 

    # Update the paths in the Fortran linker flags at run time
    rcfile.append_lines <<~MATLAB
      [~, homebrew_prefix] = system ('brew --prefix');
      homebrew_prefix = strtrim (homebrew_prefix);
      [~, fortran_machine] = system ('gfortran -dumpmachine');
      fortran_machine = strtrim (fortran_machine);
      [~, fortran_version] = system ('gfortran -dumpversion');
      fortran_version = regexp (fortran_version, '[^\.]*', 'match'){1};  # major version
      setenv ('FLIBS', ...
        ['-L', fullfile(homebrew_prefix, 'opt/gcc/lib/gcc/current/gcc', fortran_machine, fortran_version), ...
        ' -L', fullfile(homebrew_prefix, 'opt/gcc/lib/gcc/current/gcc'), ...
        ' -L', fullfile(homebrew_prefix, 'opt/gcc/lib/gcc/current'), ...
        ' -lemutls_w -lheapt_w -lgfortran -lquadmath']);
    MATLAB

This is assuming that brew is always installed when using Octave from Homebrew. It is also assuming that gfortran is installed as a dependency of Octave. (Edit: Looking at the build recipe: It is a dependency.) Please let me know if that is not the case, and I can try to adapt for that.

Also please note that I don't know whether the above change is valid Ruby syntax. (It is valid Octave syntax.) But I hope you can see what I attempted to do.

[mmuetzel]

Pinging @cho-m because he gave some input in #201376. (I hope that is ok.)

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. To keep this pull request open, add a help wanted or in progress label.

[mmuetzel]

@cho-m, @daeho-ro: Would it be ok to use something like the code snippet proposed in https://github.com/Homebrew/homebrew-core/pull/218368#issuecomment-2792351847 to address #201376?

To check whether this is working correctly, you could try and install an Octave package that (partly) consists of Fortran sources (e.g., call pkg install -forge -verbose control inside Octave). Does that still work without errors with those changes?

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. To keep this pull request open, add a help wanted or in progress label.

[mmuetzel]

@cho-m, @daeho-ro: Did you come around to testing whether the code snippet proposed in https://github.com/Homebrew/homebrew-core/pull/218368#issuecomment-2792351847 would work? Does pkg install -forge -verbose control install correctly with that change?

I don't have access to a macOS computer. So, I can't test myself.

[daeho-ro]

I am not experts on the C related languages, I just tried to pass the CI build errors.

I understand that the flag -std=c++17 should not be required among the expectation, but I am hesitated to add many lines of prescription to resolve it. Needs help here.

cc. @Homebrew/core

[mmuetzel]

I understand that the flag -std=c++17 should not be required among the expectation, but I am hesitated to add many lines of prescription to resolve it. Needs help here.

Just to clarify: The proposed changes won't address whether an explicit -std=c++17 is needed or not.

#201376 is about the fact that some standard library locations for Fortran change when Homebrew updates gfortran. Octave uses the C++ or C compiler as the linker driver for .oct or .mex files (which need at least one C++ or C file which provides the interface to Octave). The C++ or C linker driver does not automatically add any linker flags that are required when linking Fortran object code. To make it easier for users to build .oct or .mex files that (partly) consist of Fortran code, Octave "remembers" these library locations when it is built. However, if these locations change (like they do when Homebrew updates gfortran to a newer version), what Octave "remembered" from its build time no longer matches what is actually there at runtime. To work around that issue, the proposed code snippet overrides what Octave "remembered" at its build time with flags that should still be valid after Homebrew updates gfortran to a newer version.

Without these changes, users won't be able to build .oct or .mex files that (partly) consist of Fortran sources or install packages that contain Fortran sources after Homebrew updates to a newer version of gfortran. Alternatively, Octave could be rebuilt on every update of gfortran. But the proposed change would probably avoid that build time (and hopefully avoid user frustration because it doesn't immediately work as expected if Octave isn't rebuilt by Homebrew).

[mmuetzel]

@cho-m, @daeho-ro: Did you come around to testing whether the code snippet proposed in #218368 (comment) would work? Does pkg install -forge -verbose control install correctly with that change?

I don't have access to a macOS computer. So, I can't test myself.

Our users on macOS would love to get the latest version of Octave with Homebrew. Could you please apply the changes proposed above and merge this PR?

[apjanke]

Our users on macOS would love to get the latest version of Octave with Homebrew.

In the mean time, users can grab 10.1 from the octave-app custom tap. It has landed there, and looks pretty much like the formula here. Just have to run it with the command [email protected] instead of plain octave.

$ brew tap octave-app/octave-app
$ brew install [email protected]
$ [email protected] --gui

Also, the dynare formula doesn't know about this alternate [email protected] formula, so if you're actually using dynare, this won't take care of you.

I don't have access to a macOS computer. So, I can't test myself.

I'll see about getting you remote access to a Mac build box, @mmuetzel.

[oscarbg]

Our users on macOS would love to get the latest version of Octave with Homebrew.

In the mean time, users can grab 10.1 from the octave-app custom tap. It has landed there, and looks pretty much like the formula here. Just have to run it with the command [email protected] instead of plain octave.

$ brew tap octave-app/octave-app
$ brew install [email protected]
$ [email protected] --gui

Also, the dynare formula doesn't know about this alternate [email protected] formula, so if you're actually using dynare, this won't take care of you.

I don't have access to a macOS computer. So, I can't test myself.

I'll see about getting you remote access to a Mac build box, @mmuetzel.

@apjanke : done with [email protected] and works cmdline but GUI no: [email protected] --gui octave: GUI features missing or disabled in this build

[apjanke]

@oscarbg :

done with [email protected] and works cmdline but GUI no: [email protected] --gui octave: GUI features missing or disabled in this build

Hmm. That should've worked. That [email protected] formula doesn't even have an option to do a no-GUI build. Maybe some dependency is missing from your system, that the formula is unaware of? Or some version compatibility thing with dependencies.

That's not a core Homebrew formula, so please drop by the Octave.app repo and report that as an issue there - https://github.com/octave-app/octave-app/issues - and we can figure it out.

[oscarbg]

@oscarbg :

done with [email protected] and works cmdline but GUI no: [email protected] --gui octave: GUI features missing or disabled in this build

Hmm. That should've worked. That [email protected] formula doesn't even have an option to do a no-GUI build. Maybe some dependency is missing from your system, that the formula is unaware of? Or some version compatibility thing with dependencies.

That's not a core Homebrew formula, so please drop by the Octave.app repo and report that as an issue there - https://github.com/octave-app/octave-app/issues - and we can figure it out.

@apjanke

@oscarbg :

done with [email protected] and works cmdline but GUI no: [email protected] --gui octave: GUI features missing or disabled in this build

Hmm. That should've worked. That [email protected] formula doesn't even have an option to do a no-GUI build. Maybe some dependency is missing from your system, that the formula is unaware of? Or some version compatibility thing with dependencies.

That's not a core Homebrew formula, so please drop by the Octave.app repo and report that as an issue there - https://github.com/octave-app/octave-app/issues - and we can figure it out.

@apjanke found issue and fixed it! opened issue for others to see: https://github.com/octave-app/octave-app/issues/312

[carlocab]

Cancelling tests here, since the PR has conflicts that need to be resolved anyway.

[daeho-ro]

On linux, dynare is not linked with octave

Dependencies with no linkage:
  octave

[carlocab]

dynare has broken linkage because Octave installs libraries in a non-standard path:

  /home/linuxbrew/.linuxbrew/Cellar/octave/10.2.0/lib/octave/10.2.0/liboctave.so.12 (octave)
  /home/linuxbrew/.linuxbrew/Cellar/octave/10.2.0/lib/octave/10.2.0/liboctgui.so.13 (octave)
  /home/linuxbrew/.linuxbrew/Cellar/octave/10.2.0/lib/octave/10.2.0/liboctinterp.so.13 (octave)
  /home/linuxbrew/.linuxbrew/Cellar/octave/10.2.0/lib/octave/10.2.0/liboctmex.so.1 (octave)

[github-actions[bot]]

:robot: An automated task has requested bottles to be published to this PR.

[!CAUTION] Please do not push to this PR branch before the bottle commits have been pushed, as this results in a state that is difficult to recover from. If you need to resolve a merge conflict, please use a merge commit. Do not force-push to this PR branch.