autoconf
[Top][All Lists]
Advanced

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

Re: Fortran linking on NetBSD (was: autoconf-2.50 docs...)


From: Jason Beegan
Subject: Re: Fortran linking on NetBSD (was: autoconf-2.50 docs...)
Date: Fri, 01 Jun 2001 04:49:55 +0000

> 
> Interesting...I've never had to do that myself; apparently, they fixed
> this limitation in versions of GNU/Linux from the last several years.
> 

I wonder how they fixed it.  Maybe a hack somewhere else.

There seems to be a problem with shared Fortran libraries as well.
For a shared slatec lib I get about six undefined references just
linking a trivial Fortran program.

> (GNU R defines MAIN_, MAIN__, and __main.  Are there any other
> possibilities?)
> 

I haven't noticed any others.

> Sigh...it looks like we'll need to deal with this; even if we can get
> around the problem with a flag on NetBSD, it sounds like there are more
> systems out there than we'll have hacks for.  This means a new autoconf
> test, e.g. AC_F77_MAIN_DECLARE or the like.  I'll volunteer to write it,
> but how should it work?
> 
> I suppose it could define a CPP macro F77_MAIN_DECLARE that either expands
> to nothing or expands to a dummy MAIN_, or whatever, depending upon the
> outcome of the test.  The manual would tell users to put this somewhere in
> their program if they want to link to Fortran code.
> 

That looks like the best workaround.  BTW, there is the -u flag which
I also mentioned to Patrick Welche.

     gcc -u MAIN__ main.o foobar.o -o prog -lg2c -lm

The problem with using that is if you use g77 or an f2c driver script
for the linking phase it probably won't have a -u option (g77 doesn't).
That's why I recommended the other approach.  You'll still need
a MAIN__ in the program anyway after the configuration process.

> One question is how to handle C++, which should really put extern "C" {...}
> around the declaration.  The ideal way to do that would be to bracket this
> with #ifdef __cplusplus ... #endif, but I can't think of a way to do that
> in a macro body.  Or, we could put the #ifdef in config.h, but that would
> violate the usual autoconf rules.  I guess it wouldn't be such a big deal
> for the manual to say that C++ users should write extern "C" {
> F77_MAIN_DECLARE }.
> 

That's the way Tela does it: extern "C" { int MAIN__;}.

> Another question: is it sufficient to compile a dummy Fortran file (a
> foobar subroutine), and link it with a dummy C program (an empty main(),
> plus the MAIN__ or whatever)?  Or does the C program have to actually call
> the Fortran routine for the error to occur?  I suspect not, but if so the
> AC_F77_MAIN_DECLARE test will have to be intermingled with the F77
> name-mangling detection.  Ugh.
> 

Even if the Fortran routine isn't called from the C program the problem
remains at least with gcc/g77.

> > You'll probably be saddened to hear that I added something similar to
> > the configure for your FFTW library in the NetBSD Packages Collection.
> 
> Shame on you for not sending a bug report!
> 

Offtopic suggestion:  please add libtool support to libctl for building
shared libraries.


Jason



reply via email to

[Prev in Thread] Current Thread [Next in Thread]