Re: [RFC PATCH] make libgcj_bc prims symbol sizes correct

On 15 Aug 2009, Andrew Haley told this:
> BC-compiled executables are being linked against libgcj as well as libgcj_bc.

Um:

spindle 1388 /usr/src/gcc/x86_64-spindle/x86_64-pc-linux-gnu/libjava/testsuite% eu-readelf -a Array_1.exe| grep NEEDED
  NEEDED            Shared library: [libgcj_bc.so.1]
  NEEDED            Shared library: [libc.so.6]

Looks like libgcj_bc.so.1 only to me, and libgcj_bc.so.1 is, as
intended, a nearly-empty wrapper DT_NEEDing libgcj.so.10. ldd looks like:

spindle 1391 /usr/src/gcc/x86_64-spindle/x86_64-pc-linux-gnu/libjava/testsuite% LD_LIBRARY_PATH=.:/usr/src/gcc/x86_64-spindle/x86_64-pc-linux-gnu/./libjava/.libs:/usr/src/gcc/x86_64-spindle/gcc:/usr/src/gcc/x86_64-spindle/gcc/32:/usr/src/gcc/x86_64-spindle/gcc/32/geode:.:/usr/src/gcc/x86_64-spindle/x86_64-pc-linux-gnu/./libjava/.libs:/usr/src/gcc/x86_64-spindle/gcc:/usr/src/gcc/x86_64-spindle/gcc/32:/usr/src/gcc/x86_64-spindle/gcc/32/geode ldd ./Array_1.exe
        linux-vdso.so.1 =>  (0x00007fffa595b000)
        libgcj_bc.so.1 => /usr/src/gcc/x86_64-spindle/x86_64-pc-linux-gnu/libjava/.libs/libgcj_bc.so.1 (0x00007f14c84cf000)
        libc.so.6 => /lib/libc.so.6 (0x00007f14c817d000)
        libgcj.so.10 => /usr/src/gcc/x86_64-spindle/x86_64-pc-linux-gnu/libjava/.libs/libgcj.so.10 (0x00007f14c508e000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f14c86d0000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007f14c4e73000)
        librt.so.1 => /lib/librt.so.1 (0x00007f14c4c6b000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007f14c4a67000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007f14c4852000)
        libgcc_s.so.1 => /usr/src/gcc/x86_64-spindle/gcc/libgcc_s.so.1 (0x00007f14c463e000)

which looks right to me.

Just teaching my grandfather to suck eggs here for a minute: the problem
is that the reference to the symbol burnt by ld into *Array_1.exe
itself* includes a size, and that size is derived from libgcj_bc.so,
thus is too small:

_Jv_intClass |0000000000601660|GLOBAL|OBJECT  | 4| |.bss

... versus, in libgcj.so.10:

_Jv_intClass |000000000307bcb8|GLOBAL|OBJECT  | 118| prims.cc:824|.bss

It is this mismatch that ld.so is complaining about (during copy
relocation processing, as it happens: see
sysdeps/{x86_64,i386}/dl-machine.h).

It happens to only complain if the reference's size is smaller than the
size of the symbol itself, so we could probably kludge around it by
making the reference in libgcj_bc be to a 64K long array or something
like that. But *that* is even uglier than what I proposed, and if glibc
chooses to become more paranoid (as well it might) then it'll just break
again.