(Linux ELF) dynamic libf2c.so and non-Fortran main programs
Sergio Gelato
which follow-ups are directed, but there might be some interest among
readers of comp.lang.fortran.]
I have encountered the following set-up difficulty in trying to use a
shared, ELF version of f2c's runtime library on a Linux (1.2.13) system.
I built the library from netlib's source code; there doesn't seem to
be an ELF distribution of f2c yet, and the g77 distribution for Linux
apparently only ships the static libf2c.a.
The library works fine when the main program has been compiled by f2c,
but is not suitable for linking with programs where main() is written
in a language other than Fortran, e.g. a C program that calls Fortran
subroutines. The problem is that main() actually needs to be in the
library, and call MAIN__, which is the true Fortran main program.
If the main program isn't Fortran, the linker complains that MAIN__ is
undefined, since it is referenced by the shared library.
Linking with -noinhibit-exec results in a working executable, since
the library's main() is never called; but there must be a better way
of doing this. So my question, for ELF experts out there, is: how does
one tell the linker not to treat that unsatisfied reference to MAIN__
from libf2c.so as fatal?
I would appreciate if you could send me a copy of any answer by email:
our newsfeed is unreliable. Thank you.
--
Sergio Gelato
root
exclusively used for links with main C modules.
JC
Sergio Gelato
a summary of the replies I received, as well as the solution I finally
implemented.
In article <4fgc6g$o...@ictpsp10.ictp.trieste.it>, I wrote:
>I have encountered the following set-up difficulty in trying to use a
>shared, ELF version of f2c's runtime library on a Linux (1.2.13) system.
>The library works fine when the main program has been compiled by f2c,
>but is not suitable for linking with programs where main() is written
>in a language other than Fortran, e.g. a C program that calls Fortran
>subroutines. The problem is that main() actually needs to be in the
>library, and call MAIN__, which is the true Fortran main program.
>If the main program isn't Fortran, the linker complains that MAIN__ is
>undefined, since it is referenced by the shared library.
Bob Corbett was quick to point out:
The obvious solution is to add a dummy routine named MAIN__.
I can't find fault with that, but it leaves me significant leeway
on how to do it. (See below.)
Taavo Raykoff suggested excluding some object files before building
libf2c.so. But as he himself pointed out, the resulting library no
longer works with Fortran main programs.
Ian Searle reported that on his system, his self-built shared ELF libf2c
does not yield the dreaded
/usr/lib/libf2c.so: undefined reference to `MAIN__'
error message when linking to a C main program.
The reason for this difference between his library and mine is still
unconfirmed, but I found out that he is using older versions of libc
and libm, which leads me to think he has an older version of the linker
as well. (I have GNU ld 2.6 from the 2.6.0.2 binutils; could it be that
late 2.5 versions were less picky about undefined symbols?)
Reading through the ELF paper by HJ Lu, I found out about the weak_alias()
macro in /usr/include/gnu-stabs.h and decided to try and implement Bob
Corbett's sibylline suggestion as follows:
/* Cut here */
#include <stdio.h>
#include <stdlib.h>
#include <gnu-stabs.h>
weak_alias(missing_MAIN__,MAIN__); /* <------- here lies the trick */
void missing_MAIN__ (void)
{
fprintf(stderr, "The Fortran main program is missing.\n");
abort();
}
/* and here */
I compiled all library routines, plus the above, with
gcc -fpic -O6 -fomit-frame-pointer -c
then linked them all together (missing_MAIN__ first, but I don't think
it matters) with
gcc -shared -o libf2c.so.1.0.1
The resulting library can successfully be linked both against a C main
program that doesn't define MAIN__ and against a Fortran main program
(that defines MAIN__ but relies on the library to supply main).
I verified that MAIN__ was indeed invoked from the library (i.e., that
the weak alias definition had been overridden) by making f_init and f_exit
print out a "been here" message. I conclude that the solution is working.
The only drawback is that if you link together a set of routines that
define neither main nor MAIN__, you won't find out about it until you
try to run the executable. (I tested that too. The error message gets
printed as expected.)
Will try to package the resulting library into a binary distribution
suitable for sunsite when I get a chance. Thanks to all who responded.
--
Sergio Gelato