mainAutoconf - Support: sr #110746, GNU Autoconf 2.71: F77...


sr #110746: GNU Autoconf 2.71: F77 name-mangling fails when compiling with mpicxx

Submitter:  None
Submitted:  Fri 21 Oct 2022 10:26:42 PM UTC
Priority:  * 1 - Blocked Severity:  3 - Normal
Status:  Done Privacy:  Public
Assigned to:  None Originator Email:  -email is unavailable-
Open/Closed:  Closed Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup

Thu 14 Dec 2023 03:02:28 PM UTC, comment #3: 

I'm going to go ahead and close this as believed to be fixed.  If you encounter further problems with F77 + mpicxx + autoconf 2.72 (which will be released in about a week), please file new bug reports.

Zack Weinberg <zackw>
Group administrator
Thu 14 Dec 2023 11:45:50 AM UTC, comment #2: 

I tested configuring and compiling the library in the setup mentioned in my original submission with autoconf 2.72d and it worked fine!
However, I was unable to recreate my problem using autoconf 2.71., so I am not entirely sure I recreated the problem setup properly.

Fri 08 Dec 2023 02:20:42 AM UTC, comment #1: 

We regret the delay in responding to this bug report.

The problem you describe may have been fixed since 2.71.  Would you be able to test autoconf 2.72d <> and report whether you can now compile your library?

Unfortunately, if it hasn't been fixed, then I do not know enough about either mpicxx or Fortran to know what should be changed.  Suggestions would be welcome.

Zack Weinberg <zackw>
Group administrator
Fri 21 Oct 2022 10:26:42 PM UTC, original submission:  


I tried to compile a software library with the compiler set to mpicxx (gcc, Ubuntu 11.2.0-19ubuntu1)) and GNU Autoconf 2.71 and encountered F77 name-mangling errors during configuration with the following output to the console.

| Checking MPI and related programs
checking whether we are using MPI... yes
checking whether we are using MPI I/O... yes
checking whether we are using MPI_Init_thread... yes
checking for mpirun... mpirun
configure:                             F77 set to gfortran
configure:                              FC set to gfortran
configure:                              CC set to mpicxx
configure:                             CXX set to mpicxx
checking whether the Fortran 77 compiler works... yes
checking for Fortran 77 compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU Fortran 77... yes
checking whether gfortran accepts -g... yes
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to get verbose linking output from gfortran... -v
checking for Fortran 77 libraries of gfortran...  -L/usr/lib/gcc/x86_64-linux-gnu/11 -L/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/11/../../.. -lgfortran -lm -lquadmath
checking whether make supports the include directive... yes (GNU style)
checking for gcc... mpicxx
checking whether the compiler supports GNU C... yes
checking whether mpicxx accepts -g... yes
checking for mpicxx option to enable C11 features... unsupported
checking for mpicxx option to enable C99 features... unsupported
checking for mpicxx option to enable C89 features... unsupported
checking whether mpicxx understands -c and -o together... yes
checking dependency style of mpicxx... gcc3
checking for dummy main to link with Fortran 77 libraries... none
checking for Fortran 77 name-mangling scheme... unknown

When looking at the config.log I identified the following sequence to probably be the cause of the problem

configure:7972: checking for Fortran name-mangling scheme
configure:7986: gfortran -c -g -O2  conftest.f >&5
configure:7986: $? = 0
configure:8033: mpicxx -o conftest -O2 -Wall   conftest.c cfortran_test.o -lgfortran  -L/usr/lib/gcc/x86_64-linux-gnu/11 -L/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/11/../../.. -lgfortran -lm -lquadmath >&5
/usr/bin/ld: /tmp/ccT0CQ1j.ltrans0.ltrans.o: in function `main':
<artificial>:(.text.startup+0x9): undefined reference to `foobar()'
collect2: error: ld returned 1 exit status
configure:8033: $? = 1
configure: failed program was:
| /* confdefs.h */
| ...
/* end confdefs.h.  */
| /* Override any GCC internal prototype to avoid an error.
|    Use char because int might match the return type of a GCC
|    builtin and then its argument prototype would still apply.  */
| char foobar ();
| #ifdef F77_DUMMY_MAIN
| #  ifdef __cplusplus
|      extern "C"
| #  endif
|    int F77_DUMMY_MAIN() { return 1; }
| #endif
| #ifdef FC_DUMMY_MAIN
| #ifndef FC_DUMMY_MAIN_EQ_F77
| #  ifdef __cplusplus
|      extern "C"
| #  endifconfigure:8033: mpicxx -o conftest -O2 -Wall  
|    int FC_DUMMY_MAIN() { return 1; }
| #endif
| #endif
| int
| main (void)
| {
| return foobar ();
|   ;
|   return 0;
| }

Similar results where obtained when testing for foobar_(), FOOBAR () and FOOBAR_().
I suppose this it due to
   char foobar ();
being defined before any occurrence of
   #ifdef __cpluspluc
        extern "C"
For comparison I tried compiling the library with autoconf 2.69 installed and everything worked fine. In this case the config.log displayed an additional
   #ifdef __cpluspluc
        extern "C"
in front of
   char foobar ();.

Do you know if this will change back in future versions or what I can do to fix the name-mangling routine accordingly?

Best Regards
Hannes Brandt



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by zackw (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-12-14 zackw StatusNeed Info Done
        Open/ClosedOpen Closed
    2023-12-08 zackw Priority5 - Unprioritized 1 - Blocked
    2023-12-08 zackw StatusNone Need Info

    Back to the top

    Powered by Savane 3.12.
    Corresponding source code