JonChesterfield added a comment. I don't know how this configuration file works. Running clang from the build directory is useful when developing, but to avoid user facing regression we'd need it to run from the install directory. The use case is someone builds trunk or a release on a HPC machine and expects it to run without hacking with the environment variables, which is especially important as module systems managing the machine are likely to be hacking with the environment variables.
It's not obvious to me how that helps fedora. Maybe changing rpath is forbidden, but global installs put the shared libraries somewhere that is detectable anyway, and the config file handling has some special case to not set rpath on binaries if it would point to system anyway? That logic would probably work for openmp too - if the library we want to find is the one on the system path, great - the problem is when the library we want to find is not on the system path. However if this machinery is already implemented as something that reads a text configuration file and we can use that instead, great. I would rather we not apply this patch as-is to trunk, and further not apply it to the previous release, because it'll break anyone running clang -fopenmp who doesn't have clang globally installed. If we can add some config file change to this patch which keeps things working then sure, back-porting is fine. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D143306/new/ https://reviews.llvm.org/D143306 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
