xry111 added inline comments.
================
Comment at: clang/lib/Driver/ToolChains/Gnu.cpp:2226
+ static const char *const LoongArch64LibDirs[] = {"/lib64", "/lib"};
+ static const char *const LoongArch64Triples[] = {
----------------
SixWeining wrote:
> xry111 wrote:
> > SixWeining wrote:
> > > MaskRay wrote:
> > > > I don't know which of /lib64, /lib has been used. For purity, I'd hope
> > > > that we just have /lib, no multilib style /lib64
> > > I also don't know the actual usage of /lib64 but I just tried and it
> > > works fine if I remove /lib64.
> > I don't like `lib64` too. But for LoongArch LP64D, the path to ELF
> > interpreter is hard coded `/lib64/ld-linux-loongarch-lp64d.so.1` and it
> > seems too late to change it. And LoongArch GCC installs libstdc++ etc. for
> > LP64D into $PREFIX/lib64 by default (like x86_64).
> >
> > As a distro (LFS) maintainer: we are already hacking GCC code to get rid of
> > `/usr/lib64`.
> Thanks for the quick reply. So I should keep the /lib64 here?
I think you should keep it. A multilib distro may have `/usr/lib64`,
`/usr/lib32`, and `/usr/lib32sf` (`sf` for soft float or whatever) and make
`/usr/lib` a symlink. A "mostly 32-bit distro" may have symlink `/usr/lib` ->
`/usr/lib32`, but still capable to build & run LA64 programs with libraries in
`/usr/lib64`. Removing `lib64` will break clang on such distros with
`-mabi=64`.
Personally, I don't like `lib64`. But we can't really predict what the distro
maintainers will do (unless you say something explicitly like "a LP64D capable
distro SHALL have LP64D libraries in `/usr/lib`" in a spec).
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D130255/new/
https://reviews.llvm.org/D130255
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
