Re: gfortran run on 64bit Mac ?
Hello David, > On 29 Jan 2022, at 11:14, dmainprice via Fortran wrote: > gfortran run on 64bit Mac ? Yes, gfortran has been running on (x86_64) 64bit Mac since macOS 10.6. > Any suggestions will F77 code run ? if it will compile with gfortran, then you could expect it to run, cheers Iain > > all the best and happy year > > David Mainprice > >
[pushed] libgfortran: Fix bootstrap on targets without static_assert macro.
Although we build the library with GCC which is known to support _Static_assert this might be done on a system without the macro mapping static_assert to the compiler keyword. The use of static_assert introduced with r12-6126-g3430132f3e82 causes bootstrap to fail on such targets, fixed by using the keyword directly. tested on i686-darwin9 and x86_64-darwin18, without regressions, pushed to master as an obvious bootstrap fix (and as approved by FX). thanks Iain Signed-off-by: Iain Sandoe libgfortran/ChangeLog: * runtime/string.c (gfc_itoa): Use _Static_assert directly instead of via the static_assert macro. --- libgfortran/runtime/string.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libgfortran/runtime/string.c b/libgfortran/runtime/string.c index 21585f48dc9..5bc202320c0 100644 --- a/libgfortran/runtime/string.c +++ b/libgfortran/runtime/string.c @@ -242,8 +242,8 @@ gfc_itoa (GFC_UINTEGER_LARGEST n, char *buffer, size_t len) integers (we would need three calls), but they do suffice for all values up to 2^127, which is the largest that Fortran can produce (-HUGE(0_16)-1) with its signed integer types. */ - static_assert(sizeof(GFC_UINTEGER_LARGEST) <= 2 * sizeof(uint64_t), - "integer too large"); + _Static_assert (sizeof(GFC_UINTEGER_LARGEST) <= 2 * sizeof(uint64_t), + "integer too large"); GFC_UINTEGER_LARGEST r; r = n % TEN19; -- 2.24.3 (Apple Git-128)
Re: [Patch v3 Fortran] Fix c_float128 and c_float128_complex on targets with 128-bit long double.
Hi Folks > On 11 Aug 2021, at 11:55, Segher Boessenkool > wrote: > On Tue, Aug 10, 2021 at 04:46:11PM -0600, Sandra Loosemore wrote: >> OK. I used your wording verbatim for the first one. For the second >> one, I'm still pretty confused as I think it is at least theoretically >> possible on PowerPC to have a target with 64-bit long double (AIX?) that > > Some embedded and embedded-like subtargets use 64-bit long double by > default. You can also configure this on any Power target (not that it > will necessarily work ;-) ) > > I don't know if any subtarget with default 64-bit long double supports > Fortran. I realize that this is not directly relevant to unscrambling the PPC 128bit stuff, but aarch64-apple-darwin2x has only 64b long double and supports gfortran. (on both the new M1 desktop macOS and embedded iOS) - it is not clear to me yet if there will at some point be a transition to a 128b long double for at least the desktop version. So the permutation definitely exists for at least one non-legacy, non-embedded platform (and gfortran is very much in demand from the new M1 users). Iain >> also supports the __ibm128 format, and it would be wrong to assume that >> *any* 128-bit mode that's not long double is IEEE. > > Absolutely. Modes are not types, and types are not modes. There are > 128-bit floating point modes that are not IEEE, there are that are, and > either can be used for long double, or neither. > > > Segher
Re: Error in installing home brew
Hi Soumyadip, this mailing list is primarily for discussion of gfortran development - > On 5 Jul 2021, at 08:05, Soumyadip Sahoo via Fortran > wrote: > > Here is the error :- > soumyadipsahoo@soumyadips-MacBook-Pro ~ % sudo apt install—gfortran — You will need to file problems/errors directly with homebrew, thanks Iain
Re: Installation in MAC M1
Hello Soumyadip, > On 5 Jul 2021, at 07:18, Soumyadip Sahoo via Fortran > wrote: > > HII, I am soumyadip ,from India , I want to install fortran compiler in my > Mac Pro M1 processor . Please give me proper way to installation , it will be > very helpful. GCC (and therefore gfortran) support is experimental on M1, while you could build from source, probably the easiest way is to use homebrew (see the homebrew website for information). thanks Iain
Re: gfortran static linking under OS X (was: Re: )
Daniel Feenberg 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
Re: gfortran static linking under OS X (was: Re: )
Hi Daniel, Tobias Burnus wrote: I am not sure whether it helps, but I want to point out that libm is the math library which is on Linux usually GLIBC and I assume on OS X it is provided by the OS vendor. actually part of libSystem (but, yes, provided by the vendor) On 19.03.21 21:22, Daniel Feenberg via Fortran wrote: Is there a way to make a statically linked binary with fortran in OS X? For much of the past year I have been using: gfortran taxsim.for -static-libgfortran -static-libgcc OK - that should work - modulo the quadmath issue (if present) - .. but that is probably solvable (with some changes to the link spec). but since January I only get the error message; ld: library not found for -lm. collect2: error: ld returned 1 exit status? lm has not been needed on macOS for a [very] long time (for many releases it was simply a convenience symlink to libSystem.dylib, for the sake of OSS code that appends ‘-lm’). There doesn’t seem to be an issue with gcc-11 (master, development) or 10.2.1 (upcoming 10.3) on macOS 11 - will see if I can fire up a copy of gcc6.5 there ... Will have a think about how to fake the libm too .. not so easy these days. This is OS X 11,2,3 Big Sur and fortran version 6.3.0. This is an old version of Fortran on a very new version of macOS, at present the first supported GCC version for macOS 11 is the upcoming 10.3 release (although homebrew no doubt has a preview courtesy of FX). Is there any way you would be able to update to a newer (and eventually supported) Fortran version ? I need static linking because my users are not developers and do not have Xcode or gcc installed. understood. This is free software. I have seen postings from 2015 suggesting that I rename libquadmath.0.dylib, which I did try but which did not help. Of course I have no need for lquad precision variables, which I understand is the source of the problem. not from what you posted - it’s the absence of “libm.dylib” that results in the message. I realise that this mail contains no solutions - but will try to reproduce the issue over the weekend. cheers Iain
