https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85142
--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Sat, 31 Mar 2018, david.abdurachmanov at gmail dot com wrote: > GCC 7.3.1 is available in Fedora RISC-V stage4 and is configured with > multilib, > but only one ABI is selected. This is done to provide multilib paths, which > are > required by glibc. > > # gcc -print-multi-directory > . > # gcc -print-multi-lib > .; > lib64/lp64d;@march=rv64imafdc@mabi=lp64d If there is only one multilib, there should only be one line in the -print-multi-lib output. So something seems wrong here (whether a mistake in how the compiler was configured - you haven't provided the detailed configure options and confirmed reproducing the issue with those options with unmodified upstream GCC - or a bug in the RISC-V t-* files). > # gcc -print-multi-os-directory > . > > Based on GCC man page -print-multi-os-directory should return ../lib64/lp64d Yes, if that's where libraries such as libstdc++ are installed by GCC. > Instead of: > > lib64/lp64d;@march=rv64imafdc@mabi=lp64d > > We should have: > > ../lib64/lp64d;@march=rv64imafdc@mabi=lp64d No, that's wrong. For a multilib-disabled compiler you should have ".;" and nothing else in the -print-multi-lib output. Directory names in -print-multi-lib / -print-multi-directory output are the *non-OS* directory names, which are used to install libgcc (and crt*.o etc.) copies in lib/gcc/$target/$version. They must never contain a ".." component because that would mean the $version directory component getting lost. > All the paths seem to be related to "some lib directory" (/usr/lib) according > to man page. Only the -print-multi-os-directory names use *OS* conventions, meaning relative to a directory called lib.