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 |
carlocab
added
help wanted
|
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. |
|
I would avoid Flang until at least shared libraries are supported on macOS. Preferably after an LLVM release that marks Flang production-ready. Using Flang already comes with a disk space cost (GCC < 500 MB while LLVM+Flang ~2.6 GB) and having static linkage across dependency tree will make binaries larger. Also, we should switch Fortran in all formulae to be consistent. This can require switching C++ (libstdc++ --> libc++) and OpenMP (libgomp --> libomp) at the same time for formulae that have EDIT: There is also issue of our Flang needing to link to libc++ due to EH. So would want to try cleaning this up prior to using Flang as a dependency For now, working around GFortran seems to be the simpler option. One option could be creating an unversioned symlink in GCC and passing that at build time like Another option could be wrapping various executables in shell scripts that dynamically find the path. |
|
The following patch would update the value of the diff --git a/scripts/startup/version-rcfile b/scripts/startup/version-rcfile
--- a/scripts/startup/version-rcfile
+++ b/scripts/startup/version-rcfile
@@ -25,3 +25,16 @@ clear ("inputrc");
if (strcmp (PAGER (), "less") && isempty (getenv ("LESS")))
PAGER_FLAGS ('-e -X -P"-- less ?pB(%pB\\%):--. (f)orward, (b)ack, (q)uit$"');
endif
+
+## With Homebrew, update the paths in the Fortran compiler flags on run-time.
+[~, 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']);This assumes that I don't have access to a macOS device. So, this change is completely untested. Could someone please check if that works as expected? If it does, you should see the value of that environment variable by executing |
brew gist-logs <formula>link ORbrew configANDbrew doctoroutputVerification
brew doctoroutput saysYour system is ready to brew.and am still able to reproduce my issue.brew updateand am still able to reproduce my issue.brew doctorand 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
brewcommands)The text was updated successfully, but these errors were encountered: