Opened 5 years ago

Last modified 5 years ago

#1818 new bug

mpich build fails on mac [via petsc]

Reported by: balay Owned by: gropp
Priority: major Milestone: future
Component: mpich Keywords:
Cc:

Description (last modified by goodell)

This is on Barry's laptop. The mpich 3.0.3 build [via petsc] fails. With the error:

src/binding/f90/create_f90_real.c:73: error: expected expression before ',' token
src/binding/f90/create_f90_real.c:74: error: expected expression before ',' token
src/binding/f90/create_f90_complex.c:74: error: expected expression before ',' token
src/binding/f90/create_f90_complex.c:75: error: expected expression before ',' token

Perhaps a configure test is failing causing this issue.

checking for Fortran 90 integer kind for 8-byte integers... unavailable
checking for Fortran 90 integer kind for 4-byte integers... unavailable

This doesn't happen on similar Mac machine - [ similarly configured with ML, latest xcode & the same GNU Fortran (GCC) 4.8.1 20130404 (prerelease)] - so perhaps a bad
interaction with xcode & gfortran. But if configure is detecting a broken fortran compiler - it should give a proper message?

Attachments (3)

config.log (557.8 KB) - added by balay 5 years ago.
config.log
config.status (116.1 KB) - added by balay 5 years ago.
config.status
output (185.5 KB) - added by balay 5 years ago.
output - as captured by petsc configure

Download all attachments as: .zip

Change History (10)

Changed 5 years ago by balay

config.log

Changed 5 years ago by balay

config.status

Changed 5 years ago by balay

output - as captured by petsc configure

comment:1 Changed 5 years ago by goodell

  • Description modified (diff)

(reformat for trac)

comment:2 Changed 5 years ago by goodell

  • Milestone set to mpich-3.0.4
  • Owner set to gropp
  • Priority changed from major to minor

Bill, do you have a way you would prefer to handle this?

comment:3 Changed 5 years ago by balay

  • Milestone mpich-3.0.4 deleted
  • Priority changed from minor to major

It appears that Barry had some env variable pointing to MATLAB - which was causing gfortran to fail.

But I guess mpich configure should be checking for test failure - and reporting appropriately [and not chug along and fail further down

comment:4 Changed 5 years ago by balay

Updated info from Barry:


Here is the configure code that fails:

else
  cat > conftest.$ac_ext <<_ACEOF


        program main
        double precision aa
        open(8, file="pac_fconftest.out", form="formatted")
        write(8,*) precision(aa), ",", range(aa)
        close(8)
        end


_ACEOF
if ac_fn_fc_try_run "$LINENO"; then :

    if test -s pac_fconftest.out ; then
        pac_fc_num_model="`sed -e 's/  */ /g' pac_fconftest.out`"
        { $as_echo "$as_me:${as_lineno-$LINENO}: result: $pac_fc_num_model" >&5
$as_echo "$pac_fc_num_model" >&6; }
        FC_DOUBLE_MODEL=$pac_fc_num_model
    else
        { $as_echo "$as_me:${as_lineno-$LINENO}: result: Error" >&5
$as_echo "Error" >&6; }
        { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: No output from test program!" >&5
$as_echo "$as_me: WARNING: No output from test program!" >&2;}
    fi
    rm -f pac_fconftest.out

else

    { $as_echo "$as_me:${as_lineno-$LINENO}: result: Error" >&5
$as_echo "Error" >&6; }
    { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: Failed to run program to determine $pac_msg" >&5
$as_echo "$as_me: WARNING: Failed to run program to determine $pac_msg" >&2;}

fi

This is the output from running the compiled program:

~/Src/petsc  next $ ./a.out
dyld: lazy symbol binding failed: Symbol not found: __gfortran_transfer_integer_write
  Referenced from: /Users/barrysmith/Src/PETSc/./a.out
  Expected in: /Applications/MATLAB_R2013a.app/sys/os/maci64/libgfortran.3.dylib

dyld: Symbol not found: __gfortran_transfer_integer_write
  Referenced from: /Users/barrysmith/Src/PETSc/./a.out
  Expected in: /Applications/MATLAB_R2013a.app/sys/os/maci64/libgfortran.3.dylib

Trace/BPT trap: 5

It should do a better job of validating that the output of the program is in the expected format and generate an error otherwise.

comment:5 Changed 5 years ago by balaji

  • Milestone set to future

comment:6 Changed 5 years ago by balaji

While better error-checking is desirable, this issue is probably not the highest priority at this time.

comment:7 Changed 5 years ago by gropp

The quick fix is to make failure-to-determine a fatal error, rather than guessing. I'll make that change.

Note: See TracTickets for help on using tickets.