Re: libgcj missing symbol __data_start

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.