Skip to content

Build failure with submodules #434

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
sgeard opened this issue Apr 10, 2021 · 8 comments
Closed

Build failure with submodules #434

sgeard opened this issue Apr 10, 2021 · 8 comments
Labels
packaging Related to porting or packaging a project to fpm

Comments

@sgeard
Copy link

sgeard commented Apr 10, 2021

The attached code fails to build:

  simon@localhost autodiff (master)]$ fpm build
   + mkdir -p build/dependencies
   + mkdir -p build/gfortran_2A42023B310FA28D/autodiff
   + gfortran -c ././src/avd.f90 -Wall -Wextra -Wimplicit-interface -fPIC -fmax-errors=1 -g -fcheck=bounds -fcheck=array-temps -fbacktrace -fcoarray=single -J build/gfortran_2A42023B310FA28D/autodiff -I build/gfortran_2A42023B310FA28D/autodiff -o build/gfortran_2A42023B310FA28D/autodiff/src_avd.f90.o
   + gfortran -c app/av_utest.f90 -Wall -Wextra -Wimplicit-interface -fPIC -fmax-errors=1 -g -fcheck=bounds -fcheck=array-temps -fbacktrace -fcoarray=single -J build/gfortran_2A42023B310FA28D/autodiff -I build/gfortran_2A42023B310FA28D/autodiff -o build/gfortran_2A42023B310FA28D/autodiff/app_av_utest.f90.o
  app/av_utest.f90:19:12:
  
     19 |         u = 0.5*sin(2*a)
        |            1
  Error: Unexpected derived-type entities in binary intrinsic numeric operator ‘*’ at (1)
  compilation terminated due to -fmax-errors=1.
   Command failed
  ERROR STOP 
  
  Error termination. Backtrace:
  #0  0x4118f9 in __fpm_environment_MOD_run
          at ././src/fpm_environment.f90:144
  #1  0x476d4a in build_target
          at ././src/fpm_backend.f90:247
  #2  0x476d4a in __fpm_backend_MOD_build_package
          at ././src/fpm_backend.f90:76
  #3  0x41966b in __fpm_MOD_cmd_build
          at ./src/fpm.f90:270
  #4  0x402422 in MAIN__
          at app/main.f90:26
  #5  0x402422 in main
          at app/main.f90:9

This is a working project which builds and runs fine with makefiles. It looks as if the problem could be due to the fact that the submodule needs to be compiled after the module. As an aside I don't think fpm itself should be reporting its own call stack in the final release.

@sgeard
Copy link
Author

sgeard commented Apr 10, 2021

Seems I can't attach a tgz file :( - I'll try to think of something else

@sgeard
Copy link
Author

sgeard commented Apr 10, 2021

autodiff.gz

... but it does support .gz - go figure!
Extract with

tar xf autodiff.gz

@awvwgk awvwgk added the packaging Related to porting or packaging a project to fpm label Apr 10, 2021
@awvwgk
Copy link
Member

awvwgk commented Apr 10, 2021

I got it to build with

fpm build --profile debug --flag -fdefault-real-8

or by applying this patch to remove some implied real(4) to real(8) conversions:

diff --git a/app/av_utest.f90 b/app/av_utest.f90
index a5770f0..87935e0 100644
--- a/app/av_utest.f90
+++ b/app/av_utest.f90
@@ -16,10 +16,10 @@ program utest
         ref = T1(0.5*sin(1.0),cos(1.0)) !,-2*sin(1.0d0)) !,-4*cos(1.0d0),8*sin(1.0d0))
         call testResult_av1('T1 => sin(x)*cos(x)',ref,w)
 
-        u = 0.5*sin(2*a)
+        u = 0.5d0*sin(2*a)
         call testResult_av1('T1 => 0.5*sin(2x)',ref,u)
 
-        s = 0.5
+        s = 0.5d0
         w = s**3 + s
         ref = T1(0.5**3+0.5,3*0.5**2 + 1) !,6*0.5) !, 6, 0)
         call testResult_av1('T1 => x**3 + x',ref,w)
@@ -38,10 +38,10 @@ program utest
         ref = T2(0.5*sin(1.0),cos(1.0),-2*sin(1.0)) !,-4*cos(1.0d0),8*sin(1.0d0))
         call testResult_av2('T2 => sin(x)*cos(x)',ref,w)
 
-        u = 0.5*sin(2*a)
+        u = 0.5d0*sin(2*a)
         call testResult_av2('T2 => 0.5*sin(2x)',ref,u)
 
-        s = 0.5
+        s = 0.5d0
         w = s**3 + s
         ref = T2(0.5**3+0.5,3*0.5**2 + 1,6*0.5) !, 6, 0)
         call testResult_av2('T2 => x**3 + x',ref,w)
@@ -61,10 +61,10 @@ program utest
         ref = T3(0.5*sin(1.0),cos(1.0),-2*sin(1.0),-4*cos(1.0)) !,8*sin(1.0d0))
         call testResult_av3('T3 => sin(x)*cos(x)',ref,w)
 
-        u = 0.5*sin(2*a)
+        u = 0.5d0*sin(2*a)
         call testResult_av3('T3 => 0.5*sin(2x)',ref,u)
 
-        s = 0.5
+        s = 0.5d0
         w = s**3 + s
         ref = T3(0.5**3+0.5,3*0.5**2 + 1,6*0.5, 6)
         call testResult_av3('T3 => x**3 + x',ref,w)
@@ -94,10 +94,10 @@ program utest
         ref = T4(0.5*sin(1.0),cos(1.0),-2*sin(1.0),-4*cos(1.0),8*sin(1.0))
         call testResult_av4('T4 => sin(x)*cos(x)',ref,w)
...skipping...
         call testResult_av3('T3 => x**3 + x',ref,w)
@@ -94,10 +94,10 @@ program utest
         ref = T4(0.5*sin(1.0),cos(1.0),-2*sin(1.0),-4*cos(1.0),8*sin(1.0))
         call testResult_av4('T4 => sin(x)*cos(x)',ref,w)
 
-        u = 0.5*sin(2*a)
+        u = 0.5d0*sin(2*a)
         call testResult_av4('T4 => 0.5*sin(2x)',ref,u)
 
-        s = 0.5
+        s = 0.5d0
         w = s**3 + s
         ref = T4(0.5**3+0.5,3*0.5**2 + 1,6*0.5, 6, 0)
         call testResult_av4('T4 => x**3 + x',ref,w)
@@ -142,11 +142,11 @@ program utest
         ref = T4(t*y,1+log(2.0)+log(t),1/t,-1/t**2,2/t**3)
         call testResult_av4('T4 => x*log(2x)',ref,w)
 
-        u = 0.5*sinh(2*a)
+        u = 0.5d0*sinh(2*a)
         ref = T4(0.5*sinh(1.0),cosh(1.0),2*sinh(1.0),4*cosh(1.0),8*sinh(1.0))
         call testResult_av4('T4 => 0.5*sinh(2x)',ref,u)
 
-        u = 0.5*cosh(2*a)
+        u = 0.5d0*cosh(2*a)
         ref = T4(0.5*cosh(1.0),sinh(1.0),2*cosh(1.0),4*sinh(1.0),8*cosh(1.0))
         call testResult_av4('T4 => 0.5*cosh(2x)',ref,u)
 

@sgeard
Copy link
Author

sgeard commented Apr 10, 2021

Nice catch. The compiler options I use in my makefiles for gfortran/debug builds:

-fPIC -cpp -std=f2018 -fimplicit-none -fdefault-real-8 -ffree-line-length-200 -Wall -Wextra -Jobj_gfortran_debug -D_DEBUG -W -ggdb -fbounds-check -ffpe-trap=denormal,invalid

and for ifort/debug builds:

-fPIC -fpp -r8 -module obj_intel_debug -D_DEBUG -g -check bounds -warn all -debug-parameters used -traceback

I never want real*4 so this gets round having to specify d0 everywhere. Can I put the compiler options in the .toml file?

@awvwgk
Copy link
Member

awvwgk commented Apr 10, 2021

Not yet, unfortunately, but we are on it. See #350 and #112 for the discussion so far.

@awvwgk
Copy link
Member

awvwgk commented Apr 10, 2021

The next best option will be the response file support John is adding with #364. This will make specifying custom arguments easier until we get the compile profiles into the package manifest.

@ivan-pi
Copy link
Member

ivan-pi commented Apr 10, 2021

I never want real*4 so this gets round having to specify d0 everywhere.

That's a nice trick, even if achieved in a non-standard way using compiler flags.

@LKedward
Copy link
Member

LKedward commented Apr 10, 2021

I never want real*4 so this gets round having to specify d0 everywhere.

That's a nice trick, even if achieved in a non-standard way using compiler flags.

I'm not so much a fan of relying on compiler flags for correctness in compilation or execution; it just causes issues when testing other compilers/build systems and makes your code difficult to use by someone else not familiar with it. Considering the small size of Sebastian's patch in this instance, the custom compiler flag doesn't seem beneficial IMO.

Since this is to do with compiler flags I'll close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
packaging Related to porting or packaging a project to fpm
Projects
None yet
Development

No branches or pull requests

4 participants