# Options for linking Fortran on a Mac

**URL:** <https://fortran-lang.discourse.group/t/options-for-linking-fortran-on-a-mac/3739>\
**Category:** Help\
**Created:** [June 13, 2022, 8:10am UTC](https://fortran-lang.discourse.group/t/options-for-linking-fortran-on-a-mac/3739 "2022-06-13T08:10:56Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\
**Post date:** [June 13, 2022, 8:10am UTC](https://fortran-lang.discourse.group/t/options-for-linking-fortran-on-a-mac/3739/1 "2022-06-13T08:10:56Z")

</div>

Over the weekend I’ve been playing with Fortran on a Mac M1 to see if there’s any future-proof ways Fortran code can be used and tied to modern UIs (only been trying free/open-source options so far).  
Here’s what I found:

- most GNU software and libraries can be very easily used through homebrew (great effort!), including gfortran, openmpi, …: I can build and run large codes easily.
- However, linking doesn’t play well with macOS’s system libraries. It seems this is related to the GNU toolchain relying on a c++ standard library that’s different than the system’s one, ultimately leading to non-ABI-compatible / non-linkable code. For example, I was unable to link against the system’s OpenCL framework or the [wxWidgets library](https://github.com/wxWidgets/wxWidgets/issues/22519), which is otherwise usually very easy to build against. This is also true for some of the libraries that are shipped with homebrew: maybe they just build them with clang/clang++ whenever there’s no other options. This seems different than what happens on Windows with the MSYS2 toolchain, for example.

So the bitter conclusion of the weekend has been that Fortran on Mac will have no other options than being confined to its fenced GNU playground unless tremendous efforts are undertaken to attempt gluing libraries and make them talking to each other. Unfortunately I don’t have experience with flang/LFortran but I would be glad to learn from the community if there are viable options for large Fortran codebases.

Next weekend I plan on trying to link some code via a DLL, but I’m not sure if that’s going to be viable ( I think the safest thing will be to expose a C API anyways). Glad to hear any opinions from the community!

Federico

---

<div class="post-metadata">

**Author:** ![Aurelius\_Nero](https://avatars.discourse-cdn.com/v4/letter/a/a87d85/32.png) [@Aurelius\_Nero](https://fortran-lang.discourse.group/u/Aurelius_Nero)\
**Post date:** [June 13, 2022, 8:28am UTC](https://fortran-lang.discourse.group/t/options-for-linking-fortran-on-a-mac/3739/2 "2022-06-13T08:28:36Z")

</div>

Was this a Mac M1 or the older Intel Macs ?

---

<div class="post-metadata">

**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\
**Post date:** [June 13, 2022, 8:33am UTC](https://fortran-lang.discourse.group/t/options-for-linking-fortran-on-a-mac/3739/3 "2022-06-13T08:33:58Z")

</div>

It’s an M1 Mac. I suspect things aren’t going to be any simpler on Intel chips, as Apple system headers make usage of C++ `block` which AFAICT won’t be supported by GNU compilers any time soon

---

<div class="post-metadata">

**Author:** ![nicholaswogan](https://avatars.discourse-cdn.com/v4/letter/n/f1d935/32.png) [@nicholaswogan](https://fortran-lang.discourse.group/u/nicholaswogan)\
**Post date:** [June 13, 2022, 11:49am UTC](https://fortran-lang.discourse.group/t/options-for-linking-fortran-on-a-mac/3739/4 "2022-06-13T11:49:22Z")

</div>

I use fortran on a M1 Mac. I use CMake for all linking and managing dependencies. Works like a charm with all combinations of compilers I have tried.

You have to make sure to use iso\_c\_binding to communicate between C and Fortran.

---

<div class="post-metadata">

**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\
**Post date:** [June 13, 2022, 12:19pm UTC](https://fortran-lang.discourse.group/t/options-for-linking-fortran-on-a-mac/3739/5 "2022-06-13T12:19:39Z")

</div>

Thank you, that’s very interesting. Does that include binding GNU binary objects to clang/clang++ binaries?

---

<div class="post-metadata">

**Author:** ![nicholaswogan](https://avatars.discourse-cdn.com/v4/letter/n/f1d935/32.png) [@nicholaswogan](https://fortran-lang.discourse.group/u/nicholaswogan)\
**Post date:** [June 13, 2022, 12:31pm UTC](https://fortran-lang.discourse.group/t/options-for-linking-fortran-on-a-mac/3739/6 "2022-06-13T12:31:48Z")

</div>

Ya. You can use find\_package command in CMake. Typically big binaries will be findable with this command. Some libraries have special commands for finding them, like “FindOpenMP”.

---

<div class="post-metadata">

**Author:** ![nicholaswogan](https://avatars.discourse-cdn.com/v4/letter/n/f1d935/32.png) [@nicholaswogan](https://fortran-lang.discourse.group/u/nicholaswogan)\
**Post date:** [June 13, 2022, 12:32pm UTC](https://fortran-lang.discourse.group/t/options-for-linking-fortran-on-a-mac/3739/7 "2022-06-13T12:32:23Z")

</div>

@awvwgk is a CMake expert.

---

<div class="post-metadata">

**Author:** ![awvwgk](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/awvwgk/32/154_2.png) [@awvwgk](https://fortran-lang.discourse.group/u/awvwgk)\
**Post date:** [June 13, 2022, 2:19pm UTC](https://fortran-lang.discourse.group/t/options-for-linking-fortran-on-a-mac/3739/8 "2022-06-13T14:19:16Z")

</div>

> [@nicholaswogan](#):
>
> @awvwgk is a CMake expert.

Uh, when did I get this qualification? _Tries to hide inconspicuously._

* * *

More seriously, I didn’t observe problems with the homebrew (GCC/GFortran) and conda-forge (clang/GFortran) tool chains on both x86\_64 and Arm64 so far.

With the default compiler, Apple’s system clang, it can be tricky because some things are missing in its standard library (OpenMP for example), which means you need to be careful with the ABI (newer C++ standards in particular, like the filesystem support). However, this is mostly relevant for C++ projects were conflicting standard libraries with different ABIs can cause havoc.

For Fortran you are lucky because you bring your Fortran runtime libraries and there is no conflicting version which might be provided by the system. The best example is the conda-forge tool chain which provides a freestanding GFortran.

Regarding CMake, if you are not using it already, best stay away from it. It is not worth the time to overcome the initial steep learning curve to become a CMake expert. There are much better alternatives available, like [meson](https://mesonbuild.com).

---

<div class="post-metadata">

**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\
**Post date:** [June 13, 2022, 2:32pm UTC](https://fortran-lang.discourse.group/t/options-for-linking-fortran-on-a-mac/3739/9 "2022-06-13T14:32:39Z")

</div>

Yeah I’m specifically trying to link to Apple’s OpenCL and system UI libraries, which is what breaks the homebrew-gcc ABI. Is what you’re saying that `libgfortran` has essentially no dependencies on the system c++ library?

One option I was thinking about was to build a dynamic library with the Fortran code (maybe it only depends on libgfortran), and then link to it from Apple’s clang++ compiled C++ code, but I’m not sure it’s going to work.

---

<div class="post-metadata">

**Author:** ![awvwgk](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/awvwgk/32/154_2.png) [@awvwgk](https://fortran-lang.discourse.group/u/awvwgk)\
**Post date:** [June 13, 2022, 9:44pm UTC](https://fortran-lang.discourse.group/t/options-for-linking-fortran-on-a-mac/3739/10 "2022-06-13T21:44:05Z")

</div>

You might want to try the conda-forge tool chain (use a mambaforge installer from [Releases · conda-forge/miniforge · GitHub](https://github.com/conda-forge/miniforge/releases)), which provides a rather clear separation between Fortran and C++ compiler, install either the _gfortran_ or _fortran-compiler_ package.

My guess is that the choice of linker or compiler wrapper used for linking can be rather important. Figuring this out by hand can be difficult. A minimal build file with meson should make it easier to clearly select the language for linking using the _link\_language_ option when creating a _library_ or _executable_ target.

```auto
project(
  'abc',
  'fortran', 'cpp',
)

executable(
  meson.project_name(),
  sources: files(
    'src/a.f90',
    'src/b.cpp',
  ),
  dependencies: [
    dependency('wxwidgets', modules: ['std', 'stc']),
    dependency('opencl'),
  ],
  link_language: 'cpp',
  install: true,
)

```

---

<div class="post-metadata">

**Author:** ![nicholaswogan](https://avatars.discourse-cdn.com/v4/letter/n/f1d935/32.png) [@nicholaswogan](https://fortran-lang.discourse.group/u/nicholaswogan)\
**Post date:** [June 19, 2022, 3:53pm UTC](https://fortran-lang.discourse.group/t/options-for-linking-fortran-on-a-mac/3739/11 "2022-06-19T15:53:43Z")

</div>

CMake and Meson seem about the same to me. The biggest difference is that most projects have CMake support, while far fewer have Meson support. I’m a little annoyed that Meson is a thing because it would be much more convenient if everyone just one or the other.

---

<div class="post-metadata">

**Author:** ![awvwgk](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/awvwgk/32/154_2.png) [@awvwgk](https://fortran-lang.discourse.group/u/awvwgk)\
**Post date:** [June 19, 2022, 4:00pm UTC](https://fortran-lang.discourse.group/t/options-for-linking-fortran-on-a-mac/3739/12 "2022-06-19T16:00:41Z")

</div>

That’s a somewhat fallible argument, since it extends to any pair of build system, like autotools and CMake or fpm and CMake+CPM as well as package managers, _e.g._ pip and conda. The motivation for having yet another build system or package manager is mostly that things are difficult to do or support in the existing ones. User and developer friendliness is one of CMake’s weak points, which leaves room for other build systems to provide a better alternative.
