Re: Problem with linking to shared native library

[Andrew Haley <aph at redhat dot com>]

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.