gfortran/gcc 11.2.0 fail to find modules/headers in default search path (opt/homebrew/include or lib)

paulmadejong commented 2 years ago

`brew gist-logs <formula>` link OR `brew config` AND `brew doctor` output

HOMEBREW_VERSION: 3.3.15
ORIGIN: https://github.com/Homebrew/brew
HEAD: d603fd6426ddae27327bb51afb085653eb2d84a7
Last commit: 7 days ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: a0885e2756dadadb0ab223b69cc435fd6513f8f9
Core tap last commit: 56 minutes ago
Core tap branch: master
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_CORE_GIT_REMOTE: https://github.com/Homebrew/homebrew-core
HOMEBREW_DISPLAY: /private/tmp/com.apple.launchd.AOGZoNGvcq/org.xquartz:0
HOMEBREW_MAKE_JOBS: 10
Homebrew Ruby: 2.6.8 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: 10-core 64-bit arm_firestorm_icestorm
Clang: 13.0.0 build 1300
Git: 2.32.0 => /Applications/Xcode.app/Contents/Developer/usr/bin/git
Curl: 7.77.0 => /usr/bin/curl
macOS: 12.2.1-arm64
CLT: 13.2.0.0.1.1638488800
Xcode: 13.2.1
Rosetta 2: false

➜  ~ brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: gettext files detected at a system prefix.
These files can cause compilation and link failures, especially if they
are compiled with improper architectures. Consider removing these files:
  /usr/local/lib/libgettextlib.dylib
  /usr/local/lib/libintl.dylib
  /usr/local/include/libintl.h

Warning: Unbrewed header files were found in /usr/local/include.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.

Unexpected header files:
  /usr/local/include/libDTG.h

Warning: Unbrewed static libraries were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.

Unexpected static libraries:
  /usr/local/lib/libHirlamUtils.a
  /usr/local/lib/libHirlamUtils_fPIC.a

Verification

[x] I ran brew update and am still able to reproduce my issue.
[x] I have resolved all warnings from brew doctor and that did not fix my problem.

What were you trying to do (and why)?

Just gotten a brand new MacBook Pro 14" with M1 Pro. Used the migration assistant to transfer files from my intel MacBook Pro 13" 2017. This all worked find. Created an alias oldbrew that linked to brew in /usr/local/bin (the old intel homebrew installation). Installed homebrew for M1 in /opt/homebrew. Updated gcc and gfortran to 11.2.0 (also on my older intel MacBook Pro 13").

Now building my project requires to add additional include and library directives in CMake in order for gcc/gfortran to find brew installed libraries/headers. This wasn't required on my old MacBook Pro 13" with intel homebrew until this laptop got updated to gcc 11.2.0 as well.

The brew doctor "issues" are libraries build myself and are part of the large project I'm trying to build. Those can be found it seems, although they are in the homebrew intel version library path? Why is my (m1) brew doctor checking that location? It is not part of the gcc search path?

What happened (include all command output)?

Ever since this update, my project that uses CMake to build C, Fortran code and Python/Cython extensions requires me to explicitly set LINK_DIRECTORIES(/opt/homebrew/lib) and INCLUDE_DIRECTORIES(/opt/homebrew/include) in CMakeListst.txt for gcc/gfortran to find module files or libraries for eccodes (also instead through homebrew in /opt/homebrew.

I have asked about this issue on stack overflow (https://stackoverflow.com/questions/71196288/gcc-gfortran-11-cannot-find-headers-libraries-in-default-locations) as well. Initially I though the issue was just with a python extension using fortran. But since it seems to be more of a homebrew related issue, I figured to post the issue here as well. Am I missing something or misunderstanding how search paths work?

Building with gfortran:

buildDebug git:(master) ✗ /opt/homebrew/bin/gfortran -Wall -g -fno-second-underscore -fPIC -O3 -funroll-loops -I<project_dir>//include -I/usr/lib64/gfortran/modules/ -I<project_dir>//buildDebug -Ibuild/src.macosx-12-arm64-3.9/build/src.macosx-12-arm64-3.9 -I/opt/homebrew/lib/python3.9/site-packages/numpy/core/include -Ibuild/src.macosx-12-arm64-3.9/numpy/distutils/include -I/opt/homebrew/opt/python@3.9/Frameworks/Python.framework/Versions/3.9/include/python3.9 -c -c <project_dir>//src/pynwp/readAtmosphereGen.f90 -o build/temp.macosx-12-arm64-3.9<project_dir>//src/pynwp/readAtmosphereGen.o -DLINUX -DIS_LITTLE_ENDIAN -DUSEWALLTIME -DHAS_BLAS -DHAS_LAPACK -DGRIB32 -DTIMING -DPREC32 -fno-whole-file -g -fbounds-check
    f951: Warning: Nonexistent include directory '/usr/lib64/gfortran/modules/' [-Wmissing-include-dirs]
    f951: Warning: Nonexistent include directory 'build/src.macosx-12-arm64-3.9/build/src.macosx-12-arm64-3.9' [-Wmissing-include-dirs]
    f951: Warning: Nonexistent include directory 'build/src.macosx-12-arm64-3.9/numpy/distutils/include' [-Wmissing-include-dirs]
    <project_dir>//src/pynwp/readAtmosphereGen.f90:3:7:

        3 |   use eccodes
          |       1
    Fatal Error: Cannot open module file 'eccodes.mod' for reading at (1): No such file or directory
    compilation terminated.

eccodes.mod is in the proper location:

locate eccodes.mod
/opt/homebrew/Cellar/eccodes/2.24.2/include/eccodes.mod
/opt/homebrew/include/eccodes.mod

gfortran search path includes /opt/homebrew/include:

gfortran -E -Wp,-v -
#include <...> search starts here:
 **/opt/homebrew/include**
 /opt/homebrew/Cellar/gcc/11.2.0_3/bin/../lib/gcc/11/gcc/aarch64-apple-darwin21/11/include
 /opt/homebrew/Cellar/gcc/11.2.0_3/bin/../lib/gcc/11/gcc/aarch64-apple-darwin21/11/include-fixed
 /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks
End of search list.

What did you expect to happen?

I'd expect homebrew installed gcc/gfortran to find eccodes modules and library as their search path are pointing to the proper location:

gfortran -E -Wp,-v -
#include <...> search starts here:
 /opt/homebrew/include
 /opt/homebrew/Cellar/gcc/11.2.0_3/bin/../lib/gcc/11/gcc/aarch64-apple-darwin21/11/include
 /opt/homebrew/Cellar/gcc/11.2.0_3/bin/../lib/gcc/11/gcc/aarch64-apple-darwin21/11/include-fixed
 /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks
End of search list.

Step-by-step reproduction instructions (by running `brew` commands)

Migrate intel homebrew installation
create alias: alias -g oldbrew=/usr/local/bin/brew
install m1 homebrew installation: /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew install gcc
brew install eccodes
build using CMake or manually.

SMillerDev commented 2 years ago

Please add brew config as requested in the issue template.

paulmadejong commented 2 years ago

Please add brew config as requested in the issue template.

Done, missed the AND statement in the template. Thanks for pointing this out.

SMillerDev commented 2 years ago

GCC isn't officially supported on ARM so that might have something to do with it.

Tagging in the GCC expert @fxcoudert who might have some more insights.

paulmadejong commented 2 years ago

GCC isn't officially supported on ARM so that might have something to do with it.

Tagging in the GCC expert @fxcoudert who might have some more insights.

I have the same problem on my intel Macbook and /usr/local/include and /usr/local/lib after I updated homebrew on this machine as well (and hence, both arm and intel MacBooks run gcc/gfortran 11.2.0)

fxcoudert commented 2 years ago

gfortran search path includes /opt/homebrew/include

This is what I don't understand. It shouldn't, and on my system, it doesn't. From the terminal, with Homebrew gcc, gfortran -E -Wp,-v - gives:

#include "..." search starts here:
#include <...> search starts here:
 /opt/homebrew/Cellar/gcc/11.2.0_3/bin/../lib/gcc/11/gcc/aarch64-apple-darwin21/11/include
 /opt/homebrew/Cellar/gcc/11.2.0_3/bin/../lib/gcc/11/gcc/aarch64-apple-darwin21/11/include-fixed
 /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks
End of search list.

/usr/local/include was a special directory, and was included in the search path on Intel by default, IIRC. But /opt/homebrew/include is not, so it is expected that it is not in the search path, and that you have to add it when you need it.

paulmadejong commented 2 years ago

gfortran search path includes /opt/homebrew/include

This is what I don't understand. It shouldn't, and on my system, it doesn't. From the terminal, with Homebrew gcc, gfortran -E -Wp,-v - gives:
#include "..." search starts here:
#include <...> search starts here:
 /opt/homebrew/Cellar/gcc/11.2.0_3/bin/../lib/gcc/11/gcc/aarch64-apple-darwin21/11/include
 /opt/homebrew/Cellar/gcc/11.2.0_3/bin/../lib/gcc/11/gcc/aarch64-apple-darwin21/11/include-fixed
 /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks
End of search list.
/usr/local/include was a special directory, and was included in the search path on Intel by default, IIRC. But /opt/homebrew/include is not, so it is expected that it is not in the search path, and that you have to add it when you need it.

Interesting, zo /opt/homebrew/include shouldn't be there? Weird. And to confirm, any arm64 gcc/gfortran project requiring libs from homebrew arm will require the include and lib directories to be manually added? Good to know 😉

fxcoudert commented 2 years ago

so /opt/homebrew/include shouldn't be there?

No it shouldn't.

arm64 gcc/gfortran project requiring libs from homebrew arm will require the include and lib directories to be manually added?

Depends what you call "manually". Most software needs to be told where non-system libraries are, but they have simple flags to do to (configure, cmake, etc.) We view this as a feature not to be in the “special directories” (/usr/local/{include,lib}) by default anymore: it means that random libraries don't get picked up over the versions you would prefer to see it.

paulmadejong commented 2 years ago

Thanks for the clarification! Issue can be closed.

Homebrew / homebrew-core