https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Gaius Mulley from comment #4)
> > Created attachment 54184 [details]
> > Potential fix for target multilib_dir handling -m and -f.
> >
> > Work in progress.
>
> 1. (I think) the string you need is "multilib_os_dir" not "multilib_dir"
> (but ICBW about that .. there are many twisty passages in the determination
> of these things).
It seems that I was wrong about this ... at least on
x86_65-linux-gnu (which does use MULTILIB_OSDIRNAMES) and
*-darwin* (which does not).
It seems to DTRT.
(tested on linux with a 32b multilib)
> 2. The concern remains that the language spec handler is run pretty much
> first in the stack and there are several other claims on the command line
> that could have specs that alter (or add) flags to the command line, giving
> a different outcome to the computation of mulilib_{,os_}dir.
>
> perhaps it would be a good idea to post this and ask the opinion of someone
> like Joseph on the direction.
So ... the proposed patch seems to fix the problem for Darwin and X86_64 Linux.
definitely post it!
(we still need to fix the issue with the shared libraries hidden by the
additional -Ls but that's a one-line patch)
