Issue on X86_64?

[Lorenzo Pesce <lpesce at uchicago dot edu>]

Dear all,
I am preparing some free software that needs to work on different  
platforms (OS X, windows, Linux  x  32,64).
One problem I have is that this system is based upon a fortran core,  
a set of routines that do statistical calculations, which is used  
differently by either fortran, c or java drivers.

I package the procedures (.o) in three formats: a libroc.a and  
libroc.so and a libroc.so (as a jni lib).
I usually link the pieces of libgfortran.a (ar -x ...) so that users  
do not need to have libgfortran on their system. I then include those  
pieces when I build all the libraries.

The three formats build and work fine under gcc-4.1.1 on OS X 10.4  
(G4 or Xeon) and Linux Intel 32.

However, when I get to X86 (whether Intel or AMD) it does not work  
anymore. I can compile the files, and build the static library  
libroc.a. It works fine and I can move it from AMD to intel (not the  
other way around, but I assume it is a problem with my installation).  
However, when I try to build a dynamically linked library, gcc  
complains that
"Relocation R_X86_64_32 against 'a local symbol' can not be used when  
making a share object; recompile with -fPIC"
then it tells me it can't read symbols .o because it is a bad value.

If I link the libgfortran.so or load the libgfortran.so it works  for  
R. However, the result works either on AMD or Intel.

However, it does not work for the java jnilib because it thinks that  
it is the wrong ELF class: ELFCLASS64 (which it is).

I would like to use the .o's of libgfortran directly because that  
would allow me to have a single library for both Intel and AMD and  
also to make my development tree somewhat simpler. Not to mention  
that I would like to understand what is happening.

What am I doing wrong?

Lorenzo