https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42947
--- Comment #5 from Sergei Trofimovich <slyfox at inbox dot ru> --- I have looked at it a bit and I think the bug here is in interaction between MULTILIB_DEFAULTS and SYSROOT_SUFFIX_SPEC AFAIU normally gcc ignores spec overrides for MULTILIB_DEFAULTS. In our case values are: // from sh/sh.h expansion #define MULTILIB_DEFAULTS { "ml", "m4" } // from autogenerated multilib.h static const char *const multilib_raw[] = { ". !m4;", "m4 m4;", NULL }; // from autogenerated sysroot-suffix.h #define SYSROOT_SUFFIX_SPEC "" \ "%{m4:/m4;" \ ":}" Note even when we pass option -m4 we never append 'm4' suffix in library search path (because it's a MULTILIB_DEFAULTS). Looks like sh is one of 2 rare targets that touch t-sysroot-suffix: sh-*-elf* | sh[12346l]*-*-elf* | \ sh-*-linux* | sh[2346lbe]*-*-linux* | \ sh-*-netbsdelf* | shl*-*-netbsdelf*) tmake_file="... t-sysroot-suffix" tic6x-*-uclinux) tmake_file="t-sysroot-suffix ..." I think a few possible solutions here are: - drop SYSROOT_SUFFIX_SPEC support for sh* targets (or some of sh targets) - fix SYSROOT_SUFFIX_SPEC parsing to respect MULTILIB_DEFAULTS Does the above sound about right? I know nothing about SYSROOT_SUFFIX_SPEC. What uses it? It feels like a competing mechanism to multilib.