summaryrefslogtreecommitdiff
path: root/libjava/classpath/java/io/ObjectStreamField.java
diff options
context:
space:
mode:
authorRainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>2025-11-19 09:24:14 +0100
committerRainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>2025-11-19 09:24:14 +0100
commita264167c1eddbbdb85b466a5fde190791b1a1ec9 (patch)
treef496e12d0f25005e2ebde0c512c20f42f1a63590 /libjava/classpath/java/io/ObjectStreamField.java
parentf2e3eb726be5b386c4c5738c67f0e39fec983d38 (diff)
build: Define DISABLE_MULTILIB if --disable-multilib
When building trunk on Solaris with --disable-multilib, I noticed that the non-default multilib wasn't rejected any longer, leading to unexpected link failures. I could trace this to DISABLE_MULTILIB no longer being defined in multilib.h. The problem ist that gcc/genmultilib has been changed in Author: Terry Guo <terry.guo@arm.com> Date: Sun Jan 13 10:12:07 2013 +0000 Makefile.in (s-mlib): New argument MULTILIB_REUSE. This patch factored out the code that sets disable_multilib and controls emission of that macro into a separate generated script (tmpmultilib3), but genmultilib itself continues to check $disable_multilib that isn't ever set there. Fixed by checking enable_multilib instead which is set from the corresponding genmultilib argument. DISABLE_MULTILIB is only referenced in gcc/config/sol2.h, so no other port should be affected. Bootstrapped without regressions on i386-pc-solaris2.11 and sparc-sun-solaris2.11 and verifying that the non-default multilibs are now rejected again as expected. 2025-11-18 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> gcc: * genmultilib: Check $enable_multilib to define DISABLE_MULTILIB.
Diffstat (limited to 'libjava/classpath/java/io/ObjectStreamField.java')
0 files changed, 0 insertions, 0 deletions