-
-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Comments
This comment was marked as resolved.
This comment was marked as resolved.
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? |
I tried it. Does not change anything. |
Yes, looks like the flags are baked into
|
Yes, the paths are built into |
Had the exact same issue. Tried the solution @carlocab suggested, thankfully it worked for me. Not sure why however. |
Since the linker flags contain references to Does that work? |
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! |
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
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
It does. Though exact FLIBS would be tricky to identify unless familiar with GCC/Fortran. Using prior build output, following should work as override:
|
Thank you for testing. Linking to frameworks (e.g., for the Qt GUI) required to link all dependencies with Octave 9 or earlier. 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 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
That expression would need to be executed on run-time. Using it on build time wouldn't help if I understood the issue correctly. |
I am wonderring if compiling with
Control package works as well:
|
What does |
% mkoctfile -p FLIBS |
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? |
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. |
brew gist-logs <formula>
link ORbrew config
ANDbrew doctor
outputVerification
brew doctor
output saysYour system is ready to brew.
and am still able to reproduce my issue.brew update
and am still able to reproduce my issue.brew doctor
and that did not fix my problem.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)?
What did you expect to happen?
With self-compiled octave binary on the same system, it works fine:
Step-by-step reproduction instructions (by running
brew
commands)The text was updated successfully, but these errors were encountered: