https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
--- Comment #2 from Iain Sandoe <iains at gcc dot gnu.org> --- computing the multilib_os_dir in the language driver is not going to be easy/reliably correct, since that code is called very early and the specs applied later could well modify the command line options. On IRC I had suggested that to mitigate thus it might be possible to defer the computation by using the "%M" spec to insert the relevant multilib_os_dir entries. However, that would mean moving the production of the -I command line entries to a language spec. At the moment I cannot see how to implement that - since there are no specs to substitute for $libdir etc. So, at present, ISTM that the most reliable approach would be to follow what the c-fmaily does and compute the language-specific include paths early in the front end. ---- As noted in PR108259, the '-L' entries are not, in fact, needed (actually they break the discovery of the shared libraries) so that this part of the process can be simplified (and there is no need to consider the pre-link callback we were discussing). It seems increasingly likely that simplifying the library to a single runtime with the process of deciding which APIs are available decided by the FE is probably going to resolve a bunch of difficulties and simplify the driver at the same time (0.02GBP, only, no patches at this time).
