[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Condor-users] condor_compile + gfortran

On Tue, 7 Oct 2008 13:59:19 -0700
"Pasquale Tricarico" <tricaric@xxxxxxx> wrote:

> I've been asking for the past 2 years or so about support of gfortran
> by condor_compile, as an alternative to g77. As a matter of fact, g77
> has been replaced by gfortran on the GCC project and any recent linux
> distribution provides only gfortran and not g77. So the question is:
> is condor_compile going to support gfortran? If so, when? If not, why?

I know this doesn't directly answer your question, but it may help to
know that I've been able to condor_compile and run (in the standard
universe) at least a simple test program compiled with gfortran.

The key to remember is that you only have to LINK with condor_compile,
not necessarily compile.  So, compile your code with "gfortran -c" to
produce an intermediate object file.  Then link the object files in a
separate step using gcc or ld directly:

condor_compile gcc test.o gfortran-shim.o -lgfortran -lm -o test

"-lgfortran" tells the linker to include the libraries which implement
the Fortran routines required by gfortran.  If you'd linked with
gfortran, it would have hidden this from you, but the result is the

"gfortran-shim.o" is an object file compiled from the following C file,
which fudges things to prevent arguments between gfortran and
condor_compile's respective ways of handling things:

int main(int argc, char *argv[]) {
        return 0;

$ ./test 
Condor: Notice: Will checkpoint to ./test.ckpt
Condor: Notice: Remote system calls disabled.
 Hello World!

It doesn't matter that you're linking with a program different to the
one which you compiled with, as long as you are prepared to take action
to make sure all the symbols match up in the way they're meant to.

Hope that helps - please let me know.



Thomas White
Department of Materials Science and Metallurgy
Electron Microscopy Group (PhD Student)
University of Cambridge / Downing College