stdlib build error with fpm (macOS Apple Silicon)

[wiremoons]

Description

Hi

I have attempted to build and install stdlib using fpm build --profile release but get the following error message:

 + mkdir -p build/dependencies
 + mkdir -p build/gfortran_5F75F7C92365B9B9/stdlib
 + gfortran -c ././src/stdlib_kinds.f90 -O3 -Wimplicit-interface -fPIC -fmax-errors=1 -funroll-loops -fcoarray=single -J build/gfortran_5F75F7C92365B9B9/stdlib -I build/gfortran_5F75F7C92365B9B9/stdlib  -o build/gfortran_5F75F7C92365B9B9/stdlib/src_stdlib_kinds.f90.o
 + gfortran -c ././src/stdlib_system.F90 -O3 -Wimplicit-interface -fPIC -fmax-errors=1 -funroll-loops -fcoarray=single -J build/gfortran_5F75F7C92365B9B9/stdlib -I build/gfortran_5F75F7C92365B9B9/stdlib  -o build/gfortran_5F75F7C92365B9B9/stdlib/src_stdlib_system.F90.o
 + gfortran -c test/test_sleep.f90 -O3 -Wimplicit-interface -fPIC -fmax-errors=1 -funroll-loops -fcoarray=single -J build/gfortran_5F75F7C92365B9B9/stdlib -I build/gfortran_5F75F7C92365B9B9/stdlib  -o build/gfortran_5F75F7C92365B9B9/stdlib/test_test_sleep.f90.o
 + gfortran -c ././src/stdlib_ascii.f90 -O3 -Wimplicit-interface -fPIC -fmax-errors=1 -funroll-loops -fcoarray=single -J build/gfortran_5F75F7C92365B9B9/stdlib -I build/gfortran_5F75F7C92365B9B9/stdlib  -o build/gfortran_5F75F7C92365B9B9/stdlib/src_stdlib_ascii.f90.o
 + gfortran -c ././src/stdlib_bitsets.f90 -O3 -Wimplicit-interface -fPIC -fmax-errors=1 -funroll-loops -fcoarray=single -J build/gfortran_5F75F7C92365B9B9/stdlib -I build/gfortran_5F75F7C92365B9B9/stdlib  -o build/gfortran_5F75F7C92365B9B9/stdlib/src_stdlib_bitsets.f90.o
 + gfortran -c ././src/stdlib_optval.f90 -O3 -Wimplicit-interface -fPIC -fmax-errors=1 -funroll-loops -fcoarray=single -J build/gfortran_5F75F7C92365B9B9/stdlib -I build/gfortran_5F75F7C92365B9B9/stdlib  -o build/gfortran_5F75F7C92365B9B9/stdlib/src_stdlib_optval.f90.o
././src/stdlib_optval.f90:70:12:

   70 |     real(qp), intent(in), optional :: x
      |            1
Error: Kind -1 not supported for type REAL at (1)
compilation terminated due to -fmax-errors=1.
 <ERROR> Compilation failed for object "src_stdlib_optval.f90.o"
STOP 1

Versions being used:

% fpm -v
Version:     0.3.0, alpha
Program:     fpm(1)
Description: A Fortran package manager and build system
Home Page:   https://github.com/fortran-lang/fpm
License:     MIT
OS Type:     macOS

% gfortran --version
GNU Fortran (Homebrew GCC 11.2.0) 11.1.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% sw_vers
ProductName:	macOS
ProductVersion:	11.6
BuildVersion:	20G165

Steps used to build:

git clone https://github.com/fortran-lang/stdlib
cd stdlib
git checkout stdlib-fpm
fpm build --profile release

I am running on a new Apple computer using Apple Silicon M1 CPU - which maybe the cause? I have run into other build errors previously to do with REAL issues - so it maybe the same problem?

For reference in case it helps: urbanjost/M_strings#2

Thanks for any help / advice!

Simon

Expected Behaviour

That stdlib builds OK using fpm using gfortran on macOS arm64.

Version of stdlib

Current version obtained using the steps document above.

Platform and Architecture

macOS (arm64) Apple Silicon M1 Big Sur version 11.6

Additional Information

No response

[milancurcic]

Thanks a lot @wiremoons for reporting. kargl did warn us about this. 😄

EDITED JVDP1: remove the ID of kargl to avoid spamming this user.

[Romendakil]

The Homebrew gcc/gfortran is not build with real128 support, confer this issue from them:
issue

[Romendakil]

The Homebrew gcc/gfortran is not build with real128 support, confer this issue from them:
issue

This is the true issue by Iain Sandoe: gcc branch issue

[wiremoons]

Thanks @milancurcic and @Romendakil for the feedback, and for linking those other issues. I will keep en eye on them for now out of interest, and will re-try once a fix is available. No rush - just glad it is being looked at, and a fix is being considered. A good insight into all the hard work that goes on in the background that is not always apparent or noticed by users like me!

[jvdp1]

@milancurcic @awvwgk Is there a specific issue in fortran-lang/stdlib about data-mining of iso_fortran_env? I couldn't find one. I started something but some advices would be nice ;)

[awvwgk]

There is #485 about documenting the currently available data kinds.

The main issue here is that our tests currently use all kind parameters directly, therefore we first need a mechanism to conditionally skip tests if a kind parameter is not available. Using preprocessor in the tests is a bit tedious right now, which was the motivation to refactor the tests.

[jvdp1]

Thank you @awvwgk

The main issue here is that our tests currently use all kind parameters directly, therefore we first need a mechanism to conditionally skip tests if a kind parameter is not available.

I wrote a small Fortran program that scans iso_fortran_env and creates stdlib_kinds.f90, and common.fypp. Based on these, it should be quite easy to conditionally create tests.

Using preprocessor in the tests is a bit tedious right now, which was the motivation to refactor the tests.

I am not sure why it is tedious right now: fypp is already used for the tests.

[awvwgk]

Defining the preprocessor manually in every manual makefile and CMakeLists.txt, setting the flags again and including the preprocessor command is quite tedious. A lot to take care of to get this running smoothly in CMake and the makefile, especially the make clean requires some extra thoughts. Now with the fpm export there it got worse because the fypp preprocessed tests are currently ignored.

Makes my head ache when having to think about all those things for using the preprocessor in the tests. I personally prefer to do the cleanup first and have more confidence in the stability of the testing infrastructure.

Edit: I opened a couple of issues for the individual aspects which could be improved to make fypp easier usable for testing.

[jvdp1]

Defining the preprocessor manually in every manual makefile and CMakeLists.txt, setting the flags again and including the preprocessor command is quite tedious. A lot to take care of to get this running smoothly in CMake and the makefile, especially the make clean requires some extra thoughts. Now with the fpm export there it got worse because the fypp preprocessed tests are currently ignored.

Ok. I understand your point, and partly agree with it.

Data-mining iso_fortran_env will also lead to issues with how fpm currently handles stdlib.

[milancurcic]

Should we consider removing qp from stdlib until we can reliably support it?

[jvdp1]

Should we consider removing qp from stdlib until we can reliably support it?

I was thinking about that too. At least it would allow its use on a wider range of platforms.

[kargl]

Can you guys please stop CC'ing me of this issue? I have interest in neither fpm nor MacOS Apple silicon.