PGF Compiler does not resolve C routines correctly

[frae]

ropp_tools library functions are not resolved in configure test for ropp_io:

configure:3075: /opt/pgi/linux86/6.0/bin/pgf95 -o conftest -I/data/nwp1/frae/ropp/pgfinclude -I/opt/pgi/linux86/6.0/include -L/data/nwp1/frae/ropp/

pgflib -L/opt/pgi/linux86/6.0/lib conftest.f90 -lropp_tools -lnetcdf -ludunits >&5 /data/nwp1/frae/ropp/pgflib/libropp_tools.a(message_bs_escape.o)(.text+0x6fd): In function message_': undefined reference to print_stdout_'

/data/nwp1/frae/ropp/pgflib/libropp_tools.a(message_bs_escape.o)(.text+0x79a): In function message_': undefined reference to print_stdout_'

/data/nwp1/frae/ropp/pgflib/libropp_tools.a(message_bs_escape.o)(.text+0x819): In function message_': undefined reference to print_stdout_'

/data/nwp1/frae/ropp/pgflib/libropp_tools.a(message_bs_escape.o)(.text+0x8ac): In function message_': undefined reference to print_stdout_'

/data/nwp1/frae/ropp/pgflib/libropp_tools.a(message_bs_escape.o)(.text+0x924): In function message_': undefined reference to print_stdout_'

/data/nwp1/frae/ropp/pgflib/libropp_tools.a(message_bs_escape.o)(.text+0x9c1): In function message_': undefined reference to print_stderr_'

/data/nwp1/frae/ropp/pgflib/libropp_tools.a(message_bs_escape.o)(.text+0xa40): In function message_': undefined reference to print_stderr_'

/data/nwp1/frae/ropp/pgflib/libropp_tools.a(message_bs_escape.o)(.text+0xadd): In function message_': undefined reference to print_stderr_'

/data/nwp1/frae/ropp/pgflib/libropp_tools.a(message_bs_escape.o)(.text+0xb5c): In function message_': undefined reference to print_stderr_'

/data/nwp1/frae/ropp/pgflib/libropp_tools.a(message_bs_escape.o)(.text+0xbb3): In function message_': undefined reference to print_stdout_'

configure:3081: $? = 2

configure: failed program was:

| program main

| call message

| end program main

configure:3107: result: no

configure:3112: error: The ropp_tools library is required for the compilation of this library / program.

[frae]

Hopefully resolved by revision 661.

[marq]

Hmm,

I'm a bit worried - we are starting to make exceptions and exceptions just to get a particular compiler working. I don't think this is maintainable in the long run.

The main problem is that a C routine line print_stdout, by most compilers, is translated into a C function named print_stdout_. Many years ago, f2c introduced the idiotic convention to add a second underscore at the end of the C name whenever there is one in the name already. Unfortunately, the makers of g77 (the first free true Fortran 77 compiler) followed that convention for consistency reasons. From then on, many compilers for Linux have at least an option to use the same naming convention to ensure compatibility with older libraries, or g77-based libraries. However, some compilers do not implement this, or at least it won't be the default; and sometimes, users will switch this behaviour off.

cfortran has the additional problem that it cannot handle the second underscore automatically; therefore it must be provided manually as we did it. This is fine as long as there are only few (or one - f2c and maybe g77) follow this convention. But it gets a nightmare if more and more compilers follow. We will never be able to handle all of them, much less all possibilities users might have to change their compiler's default behaviour.

Therefore, I would propose to switch to one of the following two strategies:

• Always define the version with two underscores manually if we already have one in the name. That way, we do not need to know if the compiler (or then user) wants a second underscore or not; we simply have it always. Would that result in a problem with some compilers? Could we try this out?
• If the above is not a feasible way - maybe we should restrict ourselves to using C names without and underscore at all. This is not an option, however, if we are using external library function:-((

So, Axel, could you try to remove the ifdef's in the respective C files and run the changed versions through all the compilers we have? Do we run into trouble, or all of of them happy with the additional symbols, even if they don't need them?

[frae]

I am not sure what is meant by:

• Always define the version with two underscores manually if we already have one in the name. That way, we do not need to know if the compiler (or then user) wants a second underscore or not; we simply have it always. Would that result in a problem with some compilers? Could we try this out?

Should I just remove the ifdefs and leave the rest in? What I did now is:

#define print_stderr__ print_stderr_
#ifdef f2cFortran
#define print_stderr_ print_stderr__
#endif

This compiles through the pgf compiler fine but makes trouble with g95.

When I add a second underscore to external objects in the pgf flags, I get in trouble with the netcdf library. And there seems to be no way to force gcc to add a second underscore to its library. Apparently, this problem does not seem to be present in the netcdf library where the fortran interface also calles C routines. Why is this? Anything we can learn there?

We should also think about removing C code completely from ROPP. It is nice to print to stderr and stdout, but can't we do this in fortran as well? Or just forget about stderr and only print to stdout?

For now I leave everything as it is, and also leave the ticket open.

[Dave Offiler]

For information, g95 follows g77 double-underscore conventions (ie as per f2c). gfortran used to do the same, but since earlier this year, now uses a single-underscore model, like NAG.

Experience with the MetDB BUFR code shows that it's no use trying to force the C compiler to add (or not) underescores - maainly because there are no comiler options to do this. They have to be in the code (either manually or via cfortran.h) to match the f90 compiler model. Further, you can't mess with the f90 compiler setting to match the C, because that screws up finding its own library routines...

[Dave Offiler]

The pgf95 compiler now compiles all ropp code and passes existing ropp_test at v0.9.