Closed ischoegl closed 1 year ago
bryanwweber
commented
2 years 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.
ischoegl
commented
2 years ago @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.5Fwiw, 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.
bryanwweber
commented
2 years ago 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 ☺️
ischoegl
commented
2 years ago :+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).
bryanwweber
commented
2 years ago 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.
ischoegl
commented
2 years ago 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).
mefuller
commented
2 years ago I'm not so familiar with clang, but if it's LLVM, could the Flang compiler be used for Apple machines instead of gFortran?
ischoegl
commented
2 years ago 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.
bryanwweber
commented
2 years ago 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.
bryanwweber
commented
2 years ago 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
ischoegl
commented
2 years ago I'd suggest relying on the existing check for Apple's compilers and set
f90_interfacetonif it's been left as default.
:+1: sounds reasonable.
speth
commented
2 years ago 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.
speth
commented
1 year ago 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
maingfortran, compilation incondaenvironment