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.
