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

[Evert Glebbeek]

On Wednesday 30 November 2005 18:46, Bill Paxton wrote:
> 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).

Yes, I tried that after sending the message and it fixes the problem. The 
crypt problem remains though. It probably has to do with Ruby being linked 
statically: if it's linked dynamically, it probably loads the proper shared 
object at runtime, but compiling it statically it has to be linked in so I 
need another library. That's what I think anyway but my attempts to clear up 
the situation haven't been very succesful so far.

> 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.

Aha. I used c2f which seemed to be ok upto the linker stage. The cfortran.h 
file looked quite complicated when I glanced at it but I'll see if I can 
figure out how to add the Intel compiler to it.

> compiler does.   Check the web page:
> http://www-zeus.desy.de/~burow/cfortran/cfortran.html

If it comes from the Zeus code I may be able to figure something out by 
talking to our local Zeus guru. I think he tried the Intel compiler once at 
some point.

> Good idea.  At this point, I'm not concerned about making lots of
> C+Fortran compiler combinations work -- just one would be nice!

I can't fully test it right now: it seems that while my Fortran compiler is a 
64 bit compiler, I still have the 32 bit C compiler installed, and they don't 
mix. I do get the same _ error message from the loader though, so it probably 
has the same problem as GCC has (which is not strange, come to think of it: 
ICC and GCC object files can be linked together without problems so it stands 
to reason the compilers behave the same).

> Although the Intel fortran might be preferred over the Lahey? 

I don't know. The Intel compiler certainly produces faster code in my 
experience and it's free (or mostly free), but we don't get it installed on 
our local machines by default.

> I seem to 
> remember Onno running into some compiler problems trying to build EZ
> using the Lahey compiler.  Did you experience anything like that? 

I think I was able to compile and run it with both the Lahey and Intel 
compilers, but I mainly use the Intel compiler because I had some weird 
crashes with the Lahey one. In some cases, however, I've found that the Intel 
compiler can produce bad floating point code in the sense that things can go 
wrong if a value is close to overflowing or underflowing. There's a compiler 
switch to take care of that at the expense of some agressive optimisations.

Evert
-- 
Evert Glebbeek, PhD student
Physics and Astronomy Department, Utrecht University
Buys Ballot Laboratory, room 762
e-mail: glebbeek at astro.uu.nl   tel. +31 (0)30 253 5235
www: http://www.phys.uu.nl/~glebbeek/