[mpich-discuss] Compiling shared libraries with Fortran 77 compiler and unexpected option

[Dave Goodell]

On Sep 7, 2011, at 12:02 PM CDT, Thomas Jahns wrote:

> On 09/07/2011 04:22 PM, Dave Goodell wrote:
>> On Sep 7, 2011, at 4:20 AM CDT, Thomas Jahns wrote:
>> 
>> I'm not 100% sure that I understand what you mean here.  Are you saying that
>> because setbotf.f lives in lib${MPIFLIBNAME}.so and MPIFLIBNAME=mpich that
>> the libmpich.so must be linked with the fortran compiler? 
> 
> No, but it must be linked with the Fortran runtime-library (at least if one
> wants to perform symbol resolution for shared libraries).

OK, understood.

>> And that furthermore applications linked via mpicc must include some
>> libraries from the fortran compiler runtime on underlying link line?
> 
> Yes, exactly, mpicc would need to include something like
> 
> -Wl,-rpath,/opt/nag-5.2.747/lib/NAG_Fortran -L/opt/nag-5.2.747/lib/NAG_Fortran -lf52
> 
> in its LIBS. I'd rather not introduce this dependency on the C part.

That's reasonable.

>> Can you give us any specifics about which compiler you are using and what the
>> internal Fortran runtime dependency is?
> 
> It's NAG Fortran 5.2.747 on Linux x86_64. The symbols in question are
> 
> __NAGf90_enter_pu
> __NAGf90_exit_pu
> __NAGf90_filename
> __NAGf90_lineno
> __NAGf90_rterr
> 
> The NAG compiler does some heavy error checking and instrumentation and these
> seem to be related to traceback functionality. I could switch all checking off,
> but that's what one typically wants to use the NAG compiler for.

Is there a way you can disable this error checking just for the build of the MPICH library itself?  AIUI the very small bit of Fortran code that actually gets built into MPICH2's library is carefully crafted to avoid needing any runtime support in the typical case.  If we can straighten out your other xFLAGS issues then you should be able to disable the extra checking for MPICH2 itself but enable it for the compiler wrappers.

-Dave