Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

octave should have matching compilers availble #201376

Open
4 tasks done
dasergatskov opened this issue Dec 16, 2024 · 15 comments
Open
4 tasks done

octave should have matching compilers availble #201376

dasergatskov opened this issue Dec 16, 2024 · 15 comments
Labels
15-arm64 Sequoia arm64 is specifically affected 15 Sequoia is specifically affected bug Reproducible Homebrew/homebrew-core bug help wanted Task(s) needing PRs from the community or maintainers

Comments

@dasergatskov
Copy link

brew gist-logs <formula> link OR brew config AND brew doctor output

% brew config
HOMEBREW_VERSION: 4.4.12
ORIGIN: https://github.com/Homebrew/brew
HEAD: 3001afe88112c13b5aafdd92e097680897060881
Last commit: 24 hours ago
Branch: stable
Core tap JSON: 16 Dec 15:42 UTC
Core cask tap JSON: 16 Dec 15:42 UTC
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 14
Homebrew Ruby: 3.3.6 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.3.6/bin/ruby
CPU: 14-core 64-bit arm_brava
Clang: 16.0.0 build 1600
Git: 2.39.5 => /Applications/Xcode.app/Contents/Developer/usr/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 15.2-arm64
CLT: 16.2.0.0.1.1733547573
Xcode: 16.2
Rosetta 2: false

Verification

  • My brew doctor output says Your system is ready to brew. and am still able to reproduce my issue.
  • I ran brew update and am still able to reproduce my issue.
  • I have resolved all warnings from brew doctor and that did not fix my problem.
  • I searched for recent similar issues at https://github.com/Homebrew/homebrew-core/issues?q=is%3Aissue and found no duplicates.

What were you trying to do (and why)?

For users to be able to install octave packages, the octave should be compiled with the same C/C+++/Fortran compilers
as on their systems. Currently there is a mismatch (at least for darwin24 systems), see e.g.
Homebrew/brew#18943 (comment)

What happened (include all command output)?

octave:1> pkg install -forge -verbose control
downloading tarball(s) from:
- https://packages.octave.org/download/control-4.1.0.tar.gz
mkdir (/var/folders/ds/5xsh6x4914x78jswflyz20c40000gn/T/oct-fvBVdD)
untar (/var/folders/ds/5xsh6x4914x78jswflyz20c40000gn/T/control-4.1.0-JcHsDy.tar.gz, /var/folders/ds/5xsh6x4914x78jswflyz20c40000gn/T/oct-fvBVdD)
checking for mkoctfile... /opt/homebrew/Cellar/octave/9.3.0/bin/mkoctfile-9.3.0 --verbose
checking for octave-config... /opt/homebrew/Cellar/octave/9.3.0/bin/octave-config-9.3.0
...<deleted>...
clang++ -std=gnu++17 -c  -fPIC -I/opt/homebrew/Cellar/octave/9.3.0/include/octave-9.3.0/octave/.. -I/opt/homebrew/Cellar/octave/9.3.0/include/octave-9.3.0/octave -I/opt/homebrew/Cellar/octave/9.3.0/include  -pthread -g -O2  -Wall -Wno-deprecated-declarations   common.cc -o /var/folders/ds/5xsh6x4914x78jswflyz20c40000gn/T//oct-DD7Qiz.o
clang++ -std=gnu++17 -I/opt/homebrew/Cellar/octave/9.3.0/include/octave-9.3.0/octave/.. -I/opt/homebrew/Cellar/octave/9.3.0/include/octave-9.3.0/octave -I/opt/homebrew/Cellar/octave/9.3.0/include  -pthread -g -O2  -Wall -Wno-deprecated-declarations -o __control_slicot_functions__.oct  /var/folders/ds/5xsh6x4914x78jswflyz20c40000gn/T//oct-pYUwFC.o /var/folders/ds/5xsh6x4914x78jswflyz20c40000gn/T//oct-DD7Qiz.o  slicotlibrary.a  -bundle -undefined dynamic_lookup -bind_at_load -bundle_loader /opt/homebrew/Cellar/octave/9.3.0/bin/octave-9.3.0 -L/opt/homebrew/Cellar/octave/9.3.0/lib/octave/9.3.0 -L/opt/homebrew/Cellar/octave/9.3.0/lib -bundle -undefined dynamic_lookup -bind_at_load -bundle_loader /opt/homebrew/Cellar/octave/9.3.0/bin/octave-9.3.0  -L/opt/homebrew/opt/openblas/lib -lopenblas  -L/opt/homebrew/opt/gcc/bin/../lib/gcc/current/gcc/aarch64-apple-darwin23/14 -L/opt/homebrew/opt/gcc/bin/../lib/gcc/current/gcc -L/opt/homebrew/opt/gcc/bin/../lib/gcc/current/gcc/aarch64-apple-darwin23/14/../../.. -lemutls_w -lheapt_w -lgfortran -lquadmath   -loctinterp -loctave
ld: warning: duplicate -bundle_loader option, '/opt/homebrew/Cellar/octave/9.3.0/bin/octave-9.3.0' ignored
ld: warning: search path '/opt/homebrew/opt/gcc/bin/../lib/gcc/current/gcc/aarch64-apple-darwin23/14' not found
ld: warning: search path '/opt/homebrew/opt/gcc/bin/../lib/gcc/current/gcc/aarch64-apple-darwin23/14/../../..' not found
ld: library 'emutls_w' not found
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [__control_slicot_functions__.oct] Error 1

error: pkg: error running 'make' for the control package
error: called from
    configure_make at line 117 column 9
    install at line 202 column 7
    pkg at line 619 column 9
octave:2> 

What did you expect to happen?

With self-compiled octave binary on the same system, it works fine:

clang++ -std=gnu++17 -I/usr/local/include/octave-10.0.0/octave/.. -I/usr/local/include/octave-10.0.0/octave -I/usr/local/include  -pthread -ggdb3 -O2 -march=native -mcpu=native -flto=thin  -Wall -Wno-deprecated-declarations -o __control_slicot_functions__.oct  /var/folders/ds/5xsh6x4914x78jswflyz20c40000gn/T//oct-wQ6p9k.o /var/folders/ds/5xsh6x4914x78jswflyz20c40000gn/T//oct-zBcofN.o  slicotlibrary.a  -bundle -undefined dynamic_lookup -bind_at_load  -L/usr/local/lib -bundle -undefined dynamic_lookup -bind_at_load  -L/opt/homebrew/opt/openblas/lib -lopenblas  -L/opt/homebrew/lib -L/opt/homebrew/Cellar/gcc/14.2.0_1/bin/../lib/gcc/current/gcc/aarch64-apple-darwin24/14 -L/opt/homebrew/Cellar/gcc/14.2.0_1/bin/../lib/gcc/current/gcc -L/opt/homebrew/Cellar/gcc/14.2.0_1/bin/../lib/gcc/current/gcc/aarch64-apple-darwin24/14/../../.. -lemutls_w -lheapt_w -lgfortran -lquadmath  -L/opt/homebrew/lib -bundle_loader /usr/local/bin/octave-10.0.0
copyfile /var/folders/ds/5xsh6x4914x78jswflyz20c40000gn/T/oct-rC69gC/control-4.1.0/src/__control_helper_functions__.oct /var/folders/ds/5xsh6x4914x78jswflyz20c40000gn/T/oct-rC69gC/control-4.1.0/src/__control_slicot_functions__.oct /var/folders/ds/5xsh6x4914x78jswflyz20c40000gn/T/oct-rC69gC/control-4.1.0/inst/aarch64-apple-darwin24.1.0-api-v59
The control package was installed into the directory
/Users/dmitri/.local/share/octave/api-v59/packages/control-4.1.0.

Step-by-step reproduction instructions (by running brew commands)

see above
@dasergatskov dasergatskov added the bug Reproducible Homebrew/homebrew-core bug label Dec 16, 2024

This comment was marked as resolved.

@carlocab
Copy link
Member

Can you try doing

/usr/bin/sed -i '' \
  's/aarch64-apple-darwin23/aarch64-apple-darwin24/g' \
  "$(brew --prefix octave)/lib/pkgconfig/octave.pc"

and see if it helps?

@dasergatskov
Copy link
Author

I tried it. Does not change anything.

@carlocab
Copy link
Member

Yes, looks like the flags are baked into mkoctfile. You'll probably need to rebuild octave from source with something like

brew reinstall --build-from-source octave

@carlocab carlocab added help wanted Task(s) needing PRs from the community or maintainers 15 Sequoia is specifically affected 15-arm64 Sequoia arm64 is specifically affected labels Dec 16, 2024
@dasergatskov
Copy link
Author

dasergatskov commented Dec 16, 2024

Yes, the paths are built into mkoctfile. I can build octave from source, though brew reinstall --build-from-source octave does not seem to be doing it.

@jgenc
Copy link

jgenc commented Dec 19, 2024

Had the exact same issue. Tried the solution @carlocab suggested, thankfully it worked for me. Not sure why however.

@mmuetzel
Copy link

mmuetzel commented Jan 20, 2025

mkoctfile retains some compiler and linker flags with which it was built as the default flags when it is calling a compiler or linker. That is a sensible default for most distributions.
If I understand correctly, it is not for Homebrew. Is that true?

Since the linker flags contain references to gcc, I'm assuming they might be inherited from the Fortran compiler (iiuc, that is gfortran). I could be wrong about that though.
Homebrew users can override those flags on runtime, e.g., by setting the environment variable FLIBS=" " (or by setting FLIBS to whichever Fortran library flags need to be used) while they run mkoctfile.

Does that work?

@lmem
Copy link

lmem commented Jan 25, 2025

Just signed in here to say thanks for all your efforts and to mention that I had the same issue and the suggestion by @carlocab to build from source also worked for me. (I spent an hour or two searching various forum prior to finding this too!)

I wonder if this is a result of upgrading from an Intel Mac to a Apple Silicon Mac and importing the old user? The installation paths seem to have changed between the two?

Part of my cure was to completely remove homebrew and all references to it everywhere, then reinstalled homebrew and found the issue with octave continued. So I then tried compiling octave from source and it seems to have worked. At least I now have the signal and control pkg's installed which is all I wanted!

Will also mention that building octave from source took much longer than expected, so don't get impatient when it looks like it has stalled!

@cho-m
Copy link
Member

cho-m commented Feb 16, 2025

That is a sensible default for most distributions. If I understand correctly, it is not for Homebrew. Is that true?

In usual case, these are fine in Homebrew.

Mainly we see a problem when build machine was on different major macOS than runtime machine as GCC target is kernel-specific and GCC creates target-named directories

In addition to this, there is another separate issue that the paths are resolved relative to the realpath of gfortran, so AC_F77_LIBRARY_LDFLAGS creates FLIBS with flags using fragile Cellar paths rather than opt paths:

-L/opt/homebrew/Cellar/gcc/14.2.0_1/bin/../lib/gcc/current/gcc/aarch64-apple-darwin24/14
-L/opt/homebrew/Cellar/gcc/14.2.0_1/bin/../lib/gcc/current/gcc
-L/opt/homebrew/Cellar/gcc/14.2.0_1/bin/../lib/gcc/current/gcc/aarch64-apple-darwin24/14/../../..
-lemutls_w -lheapt_w -lgfortran -lquadmath

I don't think GCC allows using an unversioned path as that would impact their target handling.

I guess simplest workaround would be a symlink hack so that newer GCC bottle contains some fake paths for older kernels that could at least make sure these can be resolved.

The Cellar paths are a bit tricky though since they break every GCC revision/version. From current build system, only option looks like manually overriding FLIBS at build time.


e.g., by setting the environment variable FLIBS=" " (or by setting FLIBS to whichever Fortran library flags need to be used) while they run mkoctfile.

Does that work?

It does. Though exact FLIBS would be tricky to identify unless familiar with GCC/Fortran.

Using prior build output, following should work as override:

-L/opt/homebrew/opt/gcc/lib/gcc/current/gcc/aarch64-apple-darwin24/14
-L/opt/homebrew/opt/gcc/lib/gcc/current
-lemutls_w -lheapt_w -lgfortran -lquadmath

@mmuetzel
Copy link

Thank you for testing.

Linking to frameworks (e.g., for the Qt GUI) required to link all dependencies with Octave 9 or earlier.
That was overhauled for Octave 10. In that version, it should be possible to build the Qt GUI without needing to link all dependencies. (The build system should be deciding that automatically - if you don't specifically enable it with --enable-link-all-dependencies.)

That means that with Octave 10 or later, this issue should be occurring for a lot less Octave packages or other .mex/.oct files (because mkoctfile won't use FLIBS in the linker flags in most cases).
Only packages that implement parts of their .oct or .mex files in Fortran will still require a correct set of flags in FLIBS.

I don't know how to implement that in Homebrew. But if I understood correctly how you described the underlying issue, an expression like the following might results in the correct set of flags for different kernels and versions of gfortran (unless something changes in its configuration):

FLIBS="-L/opt/homebrew/opt/gcc/lib/gcc/current/gcc/$(gfortran -dumpmachine)/$(gfortran -dumpversion | sed 's/\..*//') -L/opt/homebrew/opt/gcc/lib/gcc/current/gcc -L/opt/homebrew/opt/gcc/lib/gcc/current -lemutls_w -lheapt_w -lgfortran -lquadmath"

That expression would need to be executed on run-time. Using it on build time wouldn't help if I understood the issue correctly.
You probably know best how to generalize the homebrew prefix in the above expression.

@dasergatskov
Copy link
Author

I am wonderring if compiling with flang-new instead of gfortran would help with this issue?
I do this for local octave compile and so far have not encountered any issues (I had to disable visibility flags,
since flang-new does not understand that).
My configure flags for the record:

octave:2> __octave_config_info__ ("config_opts")
ans =  'SED=gsed' '--without-x' '--with-blas=-lflexiblas' 'PKG_CONFIG_PATH=/opt/homebrew/opt/qt/libexec/lib/pkgconfig' '--with-java-homedir=/opt/homebrew/opt/openjdk' 'CC=clang' 'CXX=clang++ -std=gnu++17' 'CFLAGS=-g3 -O2 -march=native -flto=thin' 'CXXFLAGS=-g3 -O2 -march=native -flto=thin' 'F77=flang-new' 'FFLAGS=-g3 -O2 -march=native' '--disable-std-pmr-polymorphic-allocator' '--disable-lib-visibility-flags' '--enable-fortran-calling-convention=gfortran' 'LDFLAGS=-L/opt/homebrew/lib -L/opt/homebrew/opt/libiconv/lib -L/opt/homebrew/opt/readline/lib' 'CPPFLAGS=-I/opt/homebrew/include -I/opt/homebrew/opt/libiconv/include -I/opt/homebrew/opt/readline/include' 

Control package works as well:

octave:3> pkg test control
Testing functions in package 'control':
...
Fixed test scripts:

                                                        total time (CPU / CLOCK)  [   3.9s /    1.7s]
Failure Summary:

  ..local/share/octave/api-v59/packages/control-4.1.1/ltimodels.m  pass   33/43  
                                                    (reported bug) XFAIL  10

Summary:

  PASS                              370
  FAIL                                0
  XFAIL (reported bug)               10
octave:4> ver
----------------------------------------------------------------------
GNU Octave Version: 10.0.1 (hg id: 21d6e8815c19)
GNU Octave License: GNU General Public License
Operating System: Darwin 24.3.0 Darwin Kernel Version 24.3.0: Thu Jan  2 20:24:22 PST 2025; root:xnu-11215.81.4~3/RELEASE_ARM64_T6041 arm64
----------------------------------------------------------------------
Package Name    | Version | Installation directory
----------------+---------+-----------------------
communications  |   1.2.7 | /Users/dmitri/.local/share/octave/api-v59/packages/communications-1.2.7
       control  |   4.1.1 | /Users/dmitri/.local/share/octave/api-v59/packages/control-4.1.1
...

@mmuetzel
Copy link

I am wonderring if compiling with flang-new instead of gfortran would help with this issue?

What does mkoctfile -p FLIBS return for that build configuration?

@dasergatskov
Copy link
Author

% mkoctfile -p FLIBS
-lto_library -L/opt/homebrew/lib -L/opt/homebrew/opt/libiconv/lib -L/opt/homebrew/opt/readline/lib -lc++ -lm -L/opt/homebrew/Cellar/flang/19.1.7_1/lib -lFortranRuntime -lFortranDecimal /opt/homebrew/opt/llvm/lib/clang/19/lib/darwin/libclang_rt.osx.a

@mmuetzel
Copy link

Looks like there are also version specific parts in there. Given the release cycle of LLVM is faster than the one of GCC, switching out gfortran with LLVM Flang might make this issue occur even more often than now.

If Flang is part of Xcode at some point in the future, maybe using that will be an option?

@carlocab
Copy link
Member

If Flang is part of Xcode at some point in the future, maybe using that will be an option?

That would make things a lot easier, but I very much doubt that will happen in the near future (and possibly ever).

Apple is too heavily invested in Swift for it to make sense for them to invest resources in a Fortran compiler for their toolchain.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
15-arm64 Sequoia arm64 is specifically affected 15 Sequoia is specifically affected bug Reproducible Homebrew/homebrew-core bug help wanted Task(s) needing PRs from the community or maintainers
Projects
None yet
Development

No branches or pull requests

6 participants