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
