https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116427
Bug ID: 116427
Summary: [15 regression] 32-bit crab1 fails to link on Solaris
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rust
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org
Target Milestone: ---
Target: i386-pc-solaris2.11, sparc-sun-solaris2.11
With the 32-bit rust build restored, I'm running into a new issue linking
crab1 on Solaris in a 32-bit-default build:
ld: warning: file
../libgrust/libformat_parser/debug/liblibformat_parser.a(libformat_parser-c75372afc1c785cf.3c7sk9t0uqs1c13c.rcgu.o):
wrong ELF class: ELFCLASS64
Undefined first referenced
symbol in file
collect_pieces rust/rust-fmt.o
clone_pieces rust/rust-fmt.o
destroy_pieces rust/rust-fmt.o
ld: fatal: symbol referencing errors
It turns out that while liblibformat_parser.a does contain definitions of those
symbols, the whole archive consists of 64-bit objects only, just as ld warns
above. In hindsight, this is no wonder since cargo is 64-bit-only (and as of
today there aren't even any 32-bit Solaris targets supported by rustc).
For other languages that need non-C++ compilers for bootstrapping (Ada, D),
the customary solution is to just build with the likes of GDC='gdc -m32' to
get the necessary 32-bit objects.
Unfortunately, even on Linux/i686 where the same issue would occur, there's
no -m32 option, and even if there were there's no way to get them into the
libgrust build given the following comment in
libgrust/libformat_parser/Makefile.am:
# TODO: Improve `cargo` invocation with host specific flags, possibly creating
a $(CARGO) variable?
I wonder what the way forward is here: just wait for gccrs to be self-contained
and cargo is no longer needed to bootstrap?
