Closed ischoegl closed 1 year ago
How was gfortran
installed? Which Python is running SCons and which is used for the Python package? Which C/C++ compiler is being used? If they're not all from conda
, I'm not surprised you're getting an error here. macOS doesn't provide a FORTRAN compiler and gfortran
isn't compatible with the Apple Clang compiler, AFAIK.
@bryanwweber ...
(base) % conda activate cantera-dev
(cantera-dev) % g++ --version
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: arm64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
(cantera-dev) % gfortran --version
GNU Fortran (Homebrew GCC 12.2.0) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
(cantera-dev) % python --version
Python 3.10.5
Fwiw, the cantera.conf
file only sets verbose_tests
.
I'm not surprised you're getting an error here. macOS doesn't provide a FORTRAN compiler and gfortran isn't compatible with the Apple Clang compiler, AFAIK.
Until yesterday, everything was working nicely within my conda
environment, so at least to me this is surprising - before, linking to clib
appears to have worked. The error log is clearly pointing at PythonExtensibleRate
; I haven't had a chance yet to compile on an Intel Mac, but I assume that it's not specific to Apple Silicon.
Fair enough! Last time I tried to mix gfortran
and Apple clang, it was bad news bears, although I don't recall the precise error ☺️
:+1: ... since I only recently started to compile on macOS, I had assumed that it 'just worked'. I haven't seen any issues on Intel macOS, although I ran into #1379 on Apple silicon (which presumably is a string handling issue).
My understanding is that the linker needs to point your executable/library at the file offset of the function it needs in the libc shared object (which is the underlying layer for most everything). As gfortran
is a GNU project, it does things one way; Apple's Clang does things a different way, and you get possible ABI (application binary interface) incompatibilities. Annoyingly, Apple provides g++
and gcc
wrappers (or maybe they're symlinks) to their own clang++
/clang
, effectively hiding that you're not using the real gcc/g++. Anyhow, I am curious if this issue or the other one is resolved by using gcc/g++ from homebrew with gfortran.
As gfortran is a GNU project, it does things one way; Apple's Clang does things a different way, and you get possible ABI (application binary interface) incompatibilities.
From a user perspective, I see two possibilities here: it should either work without restrictions, or be blocked by SCons.
As an aside, it is not limited to Apple Silicon (as expected), and things build if you set f90_interface=n
(which is hardly a surprise).
I'm not so familiar with clang
, but if it's LLVM
, could the Flang
compiler be used for Apple machines instead of gFortran
?
After running into an unrelated issue with Intel compilers (again, gfortran
was "helpfully" detected, leading to a compilation of the f90_interface
based on default options), I am starting to think that mixing compilers may not be a good idea in general. If there's a consensus, I'd rather just 'block' them for f90_interface=default
unless consistent build tools are used.
Yes, if you were using the clang from Homebrew, I think you'd use flang also from homebrew. My understanding is that the key is really that the linker has to be compatible between the compilers. Apple makes unknown modifications to their version of the compilers/linker, so there's no guarantee of error-free behavior with anything other than the Apple system root, if you're using the Apple compiler set. And Apple doesn't distribute a Fortran compiler.
If you're using GCC entirely, or LLVM entirely (not Apple's version), then you should also expect error free behavior (except for bugs and user error ☺️). It's mixing things that's usually the problem.
I am starting to think that mixing compilers may not be a good idea in general.
This is a very bad idea in general ☺️
If there's a consensus, I'd rather just 'block' them for f90_interface=default unless consistent build tools are used
👍 from me on this. To avoid having to add too much logic, I'd suggest relying on the existing check for Apple's compilers and set f90_interface
to n
if it's been left as default. If someone explicitly configures f90_interface=y
, caveat emptor ☺️ I'd personally avoid trying to implement a general check for mixing compilers, there are too many rabbit holes there of different versions and such, it doesn't seem worth it, and macos with default Apple compilers seems to be the main place this comes up
I'd suggest relying on the existing check for Apple's compilers and set
f90_interface
ton
if it's been left as default.
:+1: sounds reasonable.
Isn't the issue in this case just that we're failing to link to libpython3.X
? I guess this is an oversight on my part in the SCons updates for #1382. I think the reason why it doesn't cause the same problem on Linux, where we are more likely to have the Fortran module enabled, is because the linker there doesn't check for all the symbols being available until you're linking an executable rather than a library.
This issue was fixed by #1429 (though the other separately-reported issues with using the Fortran interface on macOS remain).
Problem description
Compilation fails on Apple Silicon (M2) after merge of #1382
Steps to reproduce
Behavior
The build fails towards the end of the build process.
Expand Error log
System information
main
gfortran
, compilation inconda
environment