[Stellar-discuss] f95 + c + Ruby = okay on Mac. But what about linux?

[Bill Paxton]

Hi Evert,


On Nov 30, 2005, at 1:17 AM, Evert Glebbeek wrote:

>
> Anyway, current result:
>
> glebbeek at siu024: ~/Program/cfort/cfortran>make
> [...]
> ffun_main.o(.text+0x68): In function `ffun_main':
> /kasper/strknd/glebbeek/Program/cfort/cfortran/ffun_main.f:6:  
> undefined
> reference to `start_'
> /home/strknd/glebbeek/lib/libruby-static.a(string.o)(.text+0x4f2e): In
> function `rb_str_crypt':
> /home/strknd/glebbeek/Program/Ruby/ruby-1.8.3/string.c:4360: undefined
> reference to `crypt'
> /home/strknd/glebbeek/lib/libruby-static.a(dln.o)(.text+0xbc): In  
> function
> `dln_load':
> /home/strknd/glebbeek/Program/Ruby/ruby-1.8.3/dln.c:1351: undefined  
> reference
> to `dlopen'
> /home/strknd/glebbeek/lib/libruby-static.a(dln.o)
> (.text+0xd1):/home/strknd/glebbeek/Program/Ruby/ruby-1.8.3/dln.c:1356:
> undefined reference to `dlsym'
> /home/strknd/glebbeek/lib/libruby-static.a(dln.o)
> (.text+0x12d):/home/strknd/glebbeek/Program/Ruby/ruby-1.8.3/dln.c: 
> 1359:
> undefined reference to `dlclose'
> /home/strknd/glebbeek/lib/libruby-static.a(dln.o)(.text+0x5): In  
> function
> `dln_strerror':
> /home/strknd/glebbeek/Program/Ruby/ruby-1.8.3/dln.c:1193: undefined  
> reference
> to `dlerror'
> make: *** [fun] Error 1
> glebbeek at siu024: ~/Program/cfort/cfortran>
>
> The Ruby errors maybe can be ignored for now, since it might just  
> be that my
> installation is broken somehow. I'll read up on embedding Ruby into  
> another
> programme myself and see if I can fix it.

The 'crypt' errors from Ruby  are a mystery, but the 'dl' errors look  
like the -ldl was necessary after all (didn't need it on Mac).

I've changed the makefile line to this:
RUBY_LIB = -L$(RUBY_DIR) -lruby -ldl

You might try that and see if the 'dl' problems go away (I don't  
think those were there before).

>
> The ffun_main.f error is a bit more serious and the sortof headache  
> I was
> afraid of: different compilers do different things to function  
> names on
> different platforms. Apparently, the Intel Fortran compiler adds an
> underscore to the end of the function name in the object file while  
> GCC does
> not do the same for C files. Come to think of it, I think GCC does  
> the same
> for Fortran files, but it's been over a year since I was calling  
> Fortran from
> C. There has to be a way to figure out what the compiler is doing and
> compensate for that, but to do it automatically requires a script  
> to detect
> what's happening at compiletime and some C preprocessor magic, I  
> think.

The problems with underscores on function names is exactly the sort  
of thing that cfortran.h is designed to address.  In the makefile,  
there is the following line:

CFLAGS = -g -c -DAbsoftProFortran

The '-DAbsoftProFortran' is to tell cfortran.h which fortran compiler  
we're using.  It then puts the underscores in the right places.

That's the good news.  The bad news is that cfortran's list of  
compilers doesn't include all the compilers you might hope for (but  
you are in luck if you are running on VMS or Apollo or VAX or CRAY or  
NEC!).  As I mentioned in my first email about this stuff, I got it  
to work with the Absoft ProFortran compiler on the mac, but not the  
IBM xlf compiler.

If you look at cfortran.h starting about line 100, you'll see lots of  
logic/magic worrying about the differences among fortran compilers.   
The trick is to find something that it knows about that matches what  
your compiler does.   Check the web page: http://www-zeus.desy.de/ 
~burow/cfortran/cfortran.html for more info (in section II there is a  
section on "Specifying the FORTRAN compiler").

If, a big if, you can find a combination of compilers that works with  
cfortran, it seems to be a very nice solution.  It covers the bases:
	calling Fortran subroutines and functions from C
	calling C subroutines and functions from Fortran
	arg types include [BYTE|DOUBLE|FLOAT|INT|LOGICAL|LONG|SHORT][V|VV| 
VVV|...]
		where V means 1 dimension array, VV means 2 dimension, etc.
	strings and function pointers as arguments
		C or Fortran routines can be passed either direction, C to Fortran  
or Fortran to C
	can use C to directly access Fortran common blocks for communication  
of data
		(probably a bad idea in practice, but nice to know it is possible)

> Just for kicks, I'll see if I still have the Intel C compiler  
> installed and
> see what happens if I use that instead of GCC.

Good idea.  At this point, I'm not concerned about making lots of C 
+Fortran compiler combinations work -- just one would be nice!   
Although the Intel fortran might be preferred over the Lahey?  I seem  
to remember Onno running into some compiler problems trying to build  
EZ using the Lahey compiler.  Did you experience anything like that?   
Also, when Mac switches to Intel starting next year, I expect that  
the ifort compiler may well appear on the Mac before the Lahey one.   
Perhaps Intel C with Intel fortran will work!

Cheers,
Bill



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.srcf.ucam.org/pipermail/stellar-discuss/attachments/20051130/6b6f318b/attachment-0009.html