Problem with linking to shared native library

Fri Mar 9 11:09:00 GMT 2007

Andreas BÃ¼rgel writes:
 > Andrew Haley schrieb:
 > 
 > > > My platform:
 > > > - gcj version: 4.1.2 20061115
 > > > - binutils version: 2.17.50.0.5 20060927
 > > > - OS: openSUSE 10.2, Linux kernel 2.6.18.2-34-default
 > > > - glibc version: 2.5 (20061011)
 > > 
 > > First thing:
 > > 
 > > gcj -shared -o"libSimpleCPPLib.so" ./SimpleCPPLib.o 
 > > /usr/bin/ld: ./SimpleCPPLib.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
 > > ./SimpleCPPLib.o: could not read symbols: Bad value
 > 
 > I cannot reproduce this error message.
That's probably because you're running 32-bit and I'm running 64-bit.
However, shred libraries should always be compiled PIC.
 > > /tmp/foo
 > > mkdir -p Debug/resource
 > > gcj -O0 -g "--classpath=./:" -c de/dbt/simplelibclient/SimpleCPPLib.java -o de/dbt/simplelibclient/SimpleCPPLib.o
 > > de/dbt/simplelibclient/SimpleCPPLib.java:3: warning: The import de.dbt.simplelibclient is never used
 > > import de.dbt.simplelibclient.*;
 > > ^^^^^^^^^^^^^^^^^^^^^^
 > > 1 problem (1 warning)
 > > gcj -O0 -g --main=de.dbt.simplelibclient.SimpleCPPLib de/dbt/simplelibclient/SimpleCPPLib.o -oDebug/SimpleLibClient -LDebug -L/home/andreas/develop/projects/SimpleCPPLib/Debug -L../SimpleCPPLib/Debug -lSimpleCPPLib -lgcj 
 > > /tmp/foo
 > 
 > I also don't get this warning, even when using "-Wall".
That'll probably be a 4.3 thing.
 > My linker error is persistent.
 > In the meantime I built gcc/gcj from the 4.1.2 release sources and binutils from
 > the 2.17 release sources and I'm using them now, but the linker error is still
 > there.
 > 
 > What versions do you use?
All of them. At the moment that means svn head (4.3 pre), 4.2, and
Red Hat 4.1.2-1.
Now, the fact is this: you just built gcc/gcj from the 4.1.2 release
sources. Therefore, the gcj you have can link C++ and Java code in
shared libraries, because that's how libgcj is built.
So, what is going on here? I'm guessing that something crazy is
happening, like compiling the C++ code with a C++ compiler from a
different release of gcc from the gcj you're using.
Andrew.