Warn if Fortran compiler does not support C-API #56
Conversation
|
Sure. What should I test exactly? |
|
Try to setup a build (there is an environment file for conda in It is supposed to fail with an error if nested functions are not supported. The plain build should work, but skip the C bindings with a warning: The file |
|
I installed gfortran using (due to conda-forge/gfortran_osx-64-feedstock#40 (comment)): Then I load it and run meson: (minpack) fortran-lang/minpack(main) $ meson setup _build -Dpython=true
The Meson build system
Version: 0.61.2
Source dir: /Users/ondrej/repos/fortran-lang/minpack
Build dir: /Users/ondrej/repos/fortran-lang/minpack/_build
Build type: native build
Project name: minpack
Project version: 2.0.0
meson.build:1:0: ERROR: Unable to detect GNU compiler type:
arm64-apple-darwin20.0.0-gfortran: fatal error: cannot execute ‘cc1’: execvp: No such file or directory
compilation terminated.
A full log can be found at /Users/ondrej/repos/fortran-lang/minpack/_build/meson-logs/meson-log.txtSo it fails, but with a different error it seems. |
|
But gfortran works for me, I tested it in the same Conda environment using: (minpack) fortran-lang/minpack(main) $ fpm new xx
+ mkdir -p xx
+ cd xx
+ mkdir -p xx/src
+ mkdir -p xx/app
+ mkdir -p xx/test
+ git config --get user.name > /var/tmp/tmp.J5u5Wx
+ git config --get user.email > /var/tmp/tmp.BkI0OG
+ git config --get user.name > /var/tmp/tmp.p9JQIL
+ git init xx
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint: git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: git branch -m <name>
Initialized empty Git repository in /Users/ondrej/repos/fortran-lang/minpack/xx/.git/
(minpack) fortran-lang/minpack(main) $ cd xx
(minpack) minpack/xx(master) $ ls
README.md app fpm.toml src test
(minpack) minpack/xx(master) $ fpm run
+ mkdir -p build/dependencies
xx.f90 done.
libxx.a done.
main.f90 done.
xx done.
[100%] Project compiled successfully.
Hello, xx! |
|
This looks like the old |
|
I have clang installed and it works. The Since gfortran seems to work for me, I assume it's a bug in Meson? |
|
It's a bug in conda-forge's GFortran setup (see conda-forge/gfortran_osx-64-feedstock#11), they delete the C compiler from GCC, however build systems like CMake and meson trying to get the version via preprocessor will be directed to the C driver of GCC which is absent and therefore fail. The ugly workaround I used for conda-forge's GFortran is create a dummy cat > cc1 <<EOF
#!/usr/bin/env bash
ARGS=()
for var in "\$@"; do
# Ignore known bad arguments
[ "\$var" != '-quiet' ] && ARGS+=("\$var")
done
"\$CC" "\${ARGS[@]}"
EOF
chmod +x cc1
PATH=$PWD:$PATH meson setup _buildThe better workaround might be to use the |
|
I see, |
|
Too bad, upgrading to a new GFortran package would solve this without hacks, but than you will run in that other issue conda-forge/gfortran_osx-64-feedstock#40 again. Not sure if it is worth to troubleshoot and workaround this further (by dropping all gcc specific arguments before calling clang) if it is an upstream bug which will get fixed eventually. Also, on MacOS/Arm64 you won't get more functionality than with fpm from the meson build anyway at the moment. |
|
Yeah, I'll wait until it's fixed upstream. I am glad |
|
I guess we can just go ahead and merge for now (checked this patch by making the code snippet invalid on purpose), unless somebody wants to test it with homebrew/macports GCC on MacOS/Arm64 first. |
Will be turned into an error in case Python bindings are enabled.
Related to #54
@Nicholaswogan @certik could you check on your Mac whether it correctly produces a warning / error with GFortran 11?