MaskRay wrote: > I [tried > asking](https://lists.openembedded.org/g/openembedded-core/topic/gcc_library_directory_and/111849200) > about this on the OpenEmbedded mailing list. The response was that it has > been this way for so long that it's going to be a major undertaking to change > it even though they would quite like to do so. > > I had a go at using symlinks to work around the problem. Unfortunately > because `ScanLibDirForGCCTriple` ends up using `../../..` to turn > `/usr/lib/gcc/${TARGET_SYS}/${gccversion}` (where `${TARGET_SYS}` is the > triple) back into just `/usr/lib` it's necessary to have real directories for > each of those components and only have symlinks below that. In other words: > > ```shell > mkdir -p $sysroot/usr/lib/gcc/arm-oemllib32-linux-gnueabi/9.5.0 > cd $sysroot/usr/lib/gcc/arm-oemllib32-linux-gnueabi/9.5.0 > ln -s ln -s ../../../arm-oemllib32-linux-gnueabi/9.5.0/* . > ``` > > Presumably there's a reason that `../../..` (made up of the `ReversePath` in > the `Suffixes` array and another `/../` when constructing `GCCParentLibPath`) > is used rather than removing components from the path or just using the > `--sysroot` path to find `/usr/lib`?
Thank you for asking OpenEmbedded. clangDriver works with many toolchains. The issue is that if each one require its own special handling in the code, it will add up, and it's definitely not a scalable solution... Ideally, the GCC code would introduce symlinks, eliminating the need for clangDriver to handle these variations. This would prevent situations where clangDriver cleanup requires OpenEmbedded users to manually verify potential breakages. https://github.com/llvm/llvm-project/pull/121302 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
