Palmer Dabbelt <pal...@sifive.com> writes: > On Tue, 29 May 2018 11:02:58 PDT (-0700), Jim Wilson wrote: > > On 05/26/2018 06:04 AM, Sebastian Huber wrote: > >> Why is the default multilib and a variant identical? > > > > This is supposed to be a single multilib, with two names. We use > > MULTILIB_REUSE to map the two names to a single multilib. > > > > rohan:1030$ ./xgcc -B./ -march=rv64imafdc -mabi=lp64d --print-libgcc > > ./rv64imafdc/lp64d/libgcc.a > > rohan:1031$ ./xgcc -B./ -march=rv64gc -mabi=lp64d --print-libgcc > > ./rv64imafdc/lp64d/libgcc.a > > rohan:1032$ ./xgcc -B./ --print-libgcc > > ./libgcc.a > > rohan:1033$ > > > > So this is working right when the -march option is given, but not > when > > no -march is given. I'd suggest a bug report so I can track this, if > > you haven't already filed one. > > IIRC this is actually a limit of the GCC build system: there needs to > be some > default multilib, and it has to be unprefixed. I wanted to keep the > library > paths orthogonal (ie, not bake in a default that rv64gc/lp64d lives at > /lib), > so I chose to just build a redundant multilib. > > It'd be great to get rid of this, but I'm afraid it's way past my level > of > understanding as to how all this works.
I do actually have a solution for this but it is not submitted upstream. MIPS has basically the same set of problems that RISC-V does in this area and in an ideal world there would be no 'fallback' multilib such that if you use compiler options that map to a library variant that does not exist then the linker just fails to find any libraries at all rather than using the default multilib. I can share the raw patch for this and try to give you some idea about how it works. I am struggling to find time to do much open source support at the moment so may not be able to do all the due diligence to get it committed. Would you be willing to take a look and do some of the work to get it in tree? Matthew
