https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43445
Eric Gallager <egallager at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2017-07-24
CC| |egallager at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Rainer Orth from comment #0)
> During a libjava build on i386-pc-solaris2.11, I noticed the following error:
>
> ld.so.1: gcj-dbtool: fatal:
> /vol/gcc/obj/gcc-4.5.0-20100208/11-gcc-gld/./gcc/libgcc_s.so.1: wrong ELF
> class: ELFCLASS32
> /bin/ksh: 29209 Killed
>
> This happens when trying to execute the 64-bit gcj-dbtool. gcj-dbtool
> itself is a libtool wrapper script, which allows it to find the dependend
> libtool
> libraries, but for libgcc_s.so.1, it relies on HOST_EXPORTS in the toplevel
> Makefile to export LD_LIBRARY_PATH via RPATH_ENVVAR, it refers to
> TARGET_LIB_PATH and HOST_LIB_PATH, but none of them is multilib aware.
>
> The toplevel Makefile probably needs to set all of LD_LIBRARY_PATH{, _32, _64}
> and their IRIX and Darwin equivalents. See
> gcc/testsuite/lib/target-libpath.exp
> for the full list.
Is this still needed now that gcj-dbtool has been removed?
