Daniel Feenberg <feenb...@nber.org> wrote:
On Fri, 19 Mar 2021, Tobias Burnus wrote:
This seems to be a OS X issue ? and I have no idea about OS X, but I
found the following:
https://github.com/fxcoudert/gfortran-for-macOS/issues/12
It is certainly an OS X issue.
Actually, it’s a gfortran issue.
There is no problem in Linux, FreeBSD or Windows with the same compiler.
As I understand it, OS X doesn't allow true dynamic linking, but it does
allow a compiler/linker to produce an executable binary which only
requires OS supplied libraries at execution time, and which includes all
the compiler specific libraries.
OSX doesn’t allow a completely statically-linked user space application.
but it does allow libgfortran and libquadmath to be statically linked - the
issue is that there’s no spec to deal with it.
Apparently the problem arises because the authors of libquadm don't want
users to use it in statically linked binaries,
no such issue, there is a static libquadmath.a installed ...
====
you should be able to work around this without changing the compiler or
rebuilding it,
find
/path/to/compiler/install/lib/libgfortran.spec
make a copy of that (for backup only)
the file contains something like:
#
# This spec file is read by gfortran when linking.
# It is used to specify the libraries we need to link in, in the right
# order.
#
%rename lib liborig
*lib: -lquadmath -lm %(libgcc) %(liborig)
change the last line line to :
*lib: %{!static-libgfortran: -lquadmath } %{static-libgfortran:
libquadmath.a%s} %(libgcc) %(liborig)
===
and try your link again
look at the linked object with “otool -Lv executable” and you should see
that it only refers to libSystem.dylib.
HTH
Iain
