RE: RISC-V ELF multilibs

[Palmer Dabbelt <palmer@sifive.com>]

On Thu, 31 May 2018 07:23:22 PDT (-0700), Matthew.Fortune@mips.com wrote:
> Palmer Dabbelt <palmer@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?

If you have a rough patch that'd be great, it'll be at least a starting point.  
Last time I poked around I wasn't ever sure where to look.

Thanks!