demeter @0.9.26 fails to build: library not found for -lgfortran

[jmroot (Joshua Root)]

Example: ​https://build.macports.org/builders/ports-11_x86_64-builder/builds/77193

It's using-L/opt/local/lib/gcc11/gcc/x86_64-apple-darwin20/11.2.0 -L/opt/local/lib/gcc11/gcc/x86_64-apple-darwin20/11.2.0/../../.. which I guess are directories installed by gcc11? There's no (direct) dependency however. It may be getting the flags from ifeffit?

Needing to depend on gcc just to link against libfgortran doesn't seem ideal, nor does having to match the gcc variant of ifeffit. Not sure how the build system is supposed to figure out the right link flags for libgcc11 though?

[cjones051073 (Chris Jones)]

If a port needs libgfortran, it should declare a path-style dependency on libgcc. i.e.

depends_lib-append path:share/doc/libgcc/README:libgcc

[jmroot (Joshua Root)]

But libgcc doesn't actually provide a libgfortran.dylib link? There's only libgfortran.5.dylib in libgcc11.

[cjones051073 (Chris Jones)]

Not directly no, but libgcc is designed to then trigger the installation of the libgccX currently providing the primary runtime, which currently is libgcc11 (and soon I will be updating to libgcc12).

The point is ports should not directly depend on a specific versioned libgccX, but libgcc.

[cjones051073 (Chris Jones)]

Note though, libgcc/libgccX provides the runtime support under /opt/local/lib/libgcc/ which is where ports should be looking for them. They should not be looking in areas like /opt/local/lib/gcc11/gcc/x86_64-apple-darwin20/11.2.0. These areas are a) only provided by the gccX ports, which are not intended to be needed by ports as a runtime dep, and b) bakes the exact gcc version in to the path used, which is fragile as this can and does change on port updates.

So it might also be that demeter needs to be educated to look for libgfortran in the correct location.

[kencu (Ken)]

By the way, Iain has been working on these issues, and most have been fixed in the latest gcc11 in Iain’s repo.

We should switch to that on all systems, I believe, and then start rebuilding (revbumping) these broken ones, which might fix a lot of issues.

in particular, I’m referring to the version-specific gcc path reference, and the lack of a reference to our alternate libgcc library path, by this.

[kencu (Ken)]

hete’s the latest release notes update

​https://github.com/iains/gcc-11-branch/commit/b8087dce36a9f4f37c47039d2558cb7541d4bf3f

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #65418.

[barracuda156]

Replying to kencu:

By the way, Iain has been working on these issues, and most have been fixed in the latest gcc11 in Iain’s repo.

We should switch to that on all systems, I believe

We should, indeed :)