MaskRay added inline comments.
================ Comment at: clang/lib/Driver/ToolChains/Gnu.cpp:2226 + static const char *const LoongArch64LibDirs[] = {"/lib64", "/lib"}; + static const char *const LoongArch64Triples[] = { ---------------- xry111 wrote: > 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). Dynamic loader selection is orthogonal to the LibDirs variable here. You can use /lib64/ld-linux-loongarch-lp64d.so.1 while the library paths are from /lib . If anything, riscv multilib support is quite broken at this point so probably don't use it as a reference. If there is ever a 32-bit distro which wants to do 64-bit compilation, you can leverage multiarch, which is less broken. https://maskray.me/blog/2021-03-28-compiler-driver-and-cross-compilation 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