core dumps related to libg2c.a

[kcfurman]

I'm trying to make an executable using f77 and C libraries with ifc / icc, however I get a core dump related to strcpy in libg2c.a.

Program received signal SIGSEGV, Segmentation fault.
0x08051e8f in strcpy ()

Has anyone else encountered this problem?

I'm able to compile everything fine with g77 / icc, but I'd like to see the speed increase with ifc.

[TimP]

strcpy() wouldn't be found in libg2c.a, although some of the functions called by g77 would use strcpy(). Trying to combine g77 and ifc compiled .o files would be a tricky business. Most of libg2c.a is incompatible with ifc. If you are using strcpy(), you should be calling it directly from C, so any problem there is a C problem, such as a bad pointer.

[kcfurman]

Thanks. Actually I determined that my problem is that you are correct that I should not be linking libg2c.a

I thought I needed it in the past since I would get a lot of undefined function references related to BLAS, and this library fixed that, however after switching to the MKL libraries, I no longer get those errors when not linking libg2c.a. The problem that remains now is related to the function MAIN__ in the C code that is not being recognized as main.

[kcfurman]

GNU Main Program Unit

I think I've now isolated what I believe to be my problem. I believe it is explained in the link above, particularly in the following key sentence:

Generally, g77 and libg2c are designed so that you need not include a main program unit written in Fortran in your program--it can be written in C or some other language.

I believe this is the case I have since the main program unit I have is written in C and many of the compiled libraries are Fortran. However, I'm not completely sure how to resolve the issue.

Would recompiling main.c from libg2c with icc be the solution? Has anyone done this before?

[TimP]

The era when certain commercial Fortrans echoed the organization of g77 is long past. While you could build f2c, using icc, and employ libg2c.a, that is an unlikely path for a normal application with a C main() and a mix of Fortran and C functions, where you are interested in using ifc. As the documents to which you refer explain, you would not use the main() of libg2c.a in an application where you have a C main().
Straying somewhat Off Topic, in a g77 application, the main() of libg2c.a calls the Fortran main program, partly in order to provide options such as getarg()/iargc().
The most likely area in which you have to watch for changes from g77 to ifc is in the calling interfaces between C and Fortran. g77 often uses double appended underscores on function/subroutine/common linkage, while ifc (and f2c, and possibly the majority of commercial compilers for linux and BSD Unix) use single appended underscores.
It remains to be seen whether the adoption of F2003 will quickly rationalize the practice of C/Fortran linkage.

[kcfurman]

Without the link to the libg2c.a library I get the following error when compiling:

/usr/lib/crt1.o: In function `_start':
/usr/lib/crt1.o(.text+0x18): undefined reference to `main'


In the C program, there is no main() per se, but MAIN__(VOID). As noted in the link, when compiling with g77, things work out okay.

Simply trying to rename MAIN__ to main in the C code has not resolved the issue. The only way I see to solve the problem without extensive changes to the code would be to create some type of equivalent to the main subroutine in libg2c.a so that MAIN__ will be "recognized" as the main program unit.

[TimP]

So, apparently, you have an application built with a C MAIN__ which acts in place of a g77-compiled main program. Further speculation is that you are relying on some of the functionality of the libg2c main(), so you may be able to deal with the issues by adding the libf2c/main.c source to your project, and modifying it to avoid gratuitous dependencies on libg2c.
The normal way is that your Fortran main program automatically invokes the functionality of the libg2c main() as well as, apparently, taking care of the function of your MAIN__. You can't have portability when your setup is so closely tied to the f2c/g77 internals. Even if you wish to keep most of your MAIN__ in C, you might consider having a simple Fortran main program which does nothing but invoke your C code.

[kcfurman]

As an experiment I downloaded the f2c source and compiled a new libf2c.a library with icc and tried that out. Linking this new library, in fact, does create a working executable. It's a kludge, but it's the best I've been able to come up with so far.

I may experiment more with creating a simple Fortran MAIN or modifying the f2c main() next week.