[cfe-dev] Library search paths on biarch systems

[Jonathan Roelofs]

The main reason I'm asking is because I'm trying to unify the 
BiarchSuffix stuff with the multilib part of MIPSABIDirSuffix so I can 
add support for multilibs in the more general case. Logically, 
MIPSABIDirSuffix seems to be doing two things: in some places it acts 
like a multilib directory suffix to the gcc installation, and other 
times it acts like a suffix to the os lib directory (i.e. 
MULTILIB_DIRNAMES vs MULTILIB_OSDIRNAMES in gcc configs).

That particular case makes it awkward because the default multilib on 
the mips toolchains isn't always appropriate, meaning there needs to be 
more to it than just keeping symmetry... so I think cpu-specific code 
here is unavoidable (and it almost certainly was anyway considering the 
multilib selection problem that comes with this project).

On 12/26/13, 7:47 PM, Chandler Carruth wrote:
>
> On Thu, Dec 26, 2013 at 9:04 PM, Jonathan Roelofs
> <jonathan at codesourcery.com <mailto:jonathan at codesourcery.com>> wrote:
>
>     Hi,
>
>     I noticed that the Linux toolchain also adds the default multilib to
>     the search path when targeting the "other" multilib that the biarch
>     gcc installation supports.  For example, in a gcc installation
>     providing two multilibs: '.;@m32' and '64;@m64', when -m64 is
>     specified on the clang command line, both <gcc>/<triple>/<ver>/64/
>     and <gcc>/<triple>/<ver>/ are added to the search paths (There's a
>     couple of tests for this specific case in
>     clang/test/Driver/linux-ld.c:__109 and
>     clang/test/Driver/cross-linux.__c:57).
>
>     Is this correct for the opposite case (i.e. gcc providing '.;@m64'
>     and '32;@m32' with -m32 on the command line) for which there don't
>     seem to be any tests for or against it? How about on PPC64?
>
>
> A long time ago, I built GCC installs and created as many directories as
> I could (even if empty) to try to test all of the search paths that it
> ended up using. It *appeared* at the time that this was intentional, and
> it made everything more complex to be asymmetrical here. I would rather
> keep the symmetry to simplify the code and logic unless doing so breaks
> something really horrible.
>
> Similarly, I'm hoping desperately that we can have the same biarch
> search pattern for PPC, x86, mips, and whatever other biarch toolchains
> we end up with. I don't want to start having different logic for each
> cpu type...

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded