> If --enable-multilib or --disable-multilib are passed then things
> are performed as today, more or less.  If these flags are not
> explicitly given then gcc has to do something different

This sounds reasonable. We could have a specific check, with the following cumulative conditions (to make it as unobtrusive as possible for current users). If:

  1. we build a native compiler
  2. on x86_64-linux (and possible other x86_64 targets whose maintainers want to opt in)
  3. and neither --enable-multilib nor --disable-multilib were passed

then:

  a. we check that the native compiler can handle 32-bit, by compiling a test executable with the "-m32" option
  b. if we fail, we error out of the configure process, indicating that this can be overriden with --{enable,disable}-multilib

I suspect this might catch (at configure time) the large majority of users who currently get stuck at stage 2 with the "gnu/stubs-32.h" error, while being invisible to a large majority of the power users.

Question: what are the pitfalls of the test proposed above? are there typical use cases that I have not thought of, and that would trigger this check?

FX


PS: I attach a tentative patch implementing such as check in configure.ac.