libgcj missing symbol __data_start
Andrew Haley
aph@redhat.com
Tue Aug 25 16:43:00 GMT 2009
Andreas Krebbel wrote:
> Hi Andrew,
>
> I see a lot of libjava fails on s390 when the -findirect-dispatch
> switch is used. The testcases fail with:
>
> /gcc-build/s390x-ibm-linux-gnu/libjava/testsuite/anonarray.exe: symbol
> lookup error:
> /gcc-build/s390x-ibm-linux-gnu/libjava/.libs/libgcj.so.11: undefined
> symbol: __data_start
>
> This symbol used to be in the .dynsym section of the main executable
> after linking. I think it was exported since libgcj.so requires
> it. But with your change libgcj_bc.so does not depend on libgcj.so
> anymore and since the link step does not directly use libgcj.so it is
> not loaded while linking the main executable what seems to lead to the
> __data_start symbol to be ommitted from the .dynsym section.
>
> rev 150852:
> ldd libgcj_bc.so
> libc.so.6 => /lib64/libc.so.6 (0x0000020000020000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000020000182000)
> /lib/ld64.so.1 (0x000002aaaaaaa000)
>
> rev 150853:
> ldd libgcj_bc.so
> libgcj.so.11 => /home/krebbel/build/gcc-build/s390x-ibm-linux-gnu/libjava/.libs/libgcj.so.11 (0x0000020000005000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00000200033bc000)
> librt.so.1 => /lib64/librt.so.1 (0x00000200033d7000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00000200033e2000)
> libz.so.1 => /lib64/libz.so.1 (0x00000200033e7000)
> libc.so.6 => /lib64/libc.so.6 (0x00000200033ff000)
> libgcc_s.so.1 => /home/krebbel/build/gcc-install/lib/../lib64/libgcc_s.so.1 (0x0000020003562000)
> /lib/ld64.so.1 (0x000002aaaaaaa000)
>
> Does that make sense to you? Could you please have a look if so?
>
> I've verified that revision 150853 introduced the failures.
Hard to say; I have no idea why s/390 should be any different from any
of the other systems. We have a s/390 here at Red Hat but it might be
easier if there's a way I could log onto your system and have a look.
Andrew.
More information about the Java
mailing list