Re: Problem with Fortran shared libraries on OSX/Darwin

[Peter O'Gorman]

Tim Jenness wrote:
> > The other problem with the static test case seems to be libtool specific, 
> > libtool should be adding the F77 libs when linking cprogram. I'll keep 
> > hacking at this, it may require that I actually brush up on my fortran, last 
> > used more than 15 years ago :(.

I have fixed libtool's fortran tests, it now fails on older version of 
fink's g77 package, but passes on the latest version.

> Our autoconf fortran guru has sorted that out for OSX. (copied to Norman).
> We are preparing patches to significantly enhance fortran 
> support in autoconf/automake.

Send them soon or you'll miss the next autoconf release :)

> The g77 man page explicitly says that -fno-common will be a mistake. 
> Especially if your fortran uses common blocks...

If there were common symbols in fortran code I can see a possible problem, 
there are not any that I see. The reason for common symbols in libg2c is 
simply people writing C code and not initializing variables when they are 
declared. The new fink version of g77 avoids this and can build shared 
libraries with current GNU libtools. There were common symbols in 
libiberty.a, libg2c.a libgcov.a, these are entirely C code, and should have 
zero effect on fortran. If you have common blocks in your own fortran code 
that you are hoping to make a shared library of, you are out of luck, file a 
bug with Apple about the impossibility of having common symbols/sections in 
MH_DYLIB output. GNU libtool will attempt to build such code with 
-fno-common which will give you unexpected results.

Please use current libtool with the new g77 from fink's unstable tree, if 
that still gives you issues complain again, but at the moment I believe that 
this issue is fixed by the new fortran compiler in fink.

Thanks,
Peter
--
Peter O'Gorman - http://www.pogma.com