Issue on X86_64?

[Andrew Haley]

Lorenzo Pesce wrote:
> 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.

You need to compile everything that goes into a dynamically linked library
with -fPIC.

> 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'm guessing you have a 32-bit JVM, so you'll need to compile the jni
library with -m32.

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

I don't think you can have a single library with both 32-bit and 64-bit
binaries.

Andrew.