arsenm added a comment. In D109885#3202213 <https://reviews.llvm.org/D109885#3202213>, @JonChesterfield wrote:
> In D109885#3198375 <https://reviews.llvm.org/D109885#3198375>, @arsenm wrote: > >> In D109885#3198340 <https://reviews.llvm.org/D109885#3198340>, >> @JonChesterfield wrote: >> >>> I'm very mistrusting of mixing a rocm toolchain with a trunk toolchain as >>> they're both quite keen on runpath and LD_LIBRARY_PATH to find internal >>> components. That makes it very easy to accidentally mix the two together >>> into something that doesn't work so personal preference is to rip out the >>> /opt/rocm search path for HSA entirely and encourage people to build it >>> from source. >> >> There are a number of cmake crimes going on in both of these, but this isn't >> one of them. LD_LIBRARY_PATH should not be used for any builds to find >> components. > > The LD_LIBRARY_PATH hazard isn't at compiler build time, it's at application > run time. E.g. someone points LD_LIBRARY_PATH at a rocm install to get libhsa > and gets that plus some rocm-distributed llvm libraries which don't > necessarily match trunk. That's a different hazard to this particular one, > except that cmake going in search of /opt/rocm suggests that arbitrary > combinations of rocm and trunk will work together when it's closer to zero > combinations work. We should have versioned libraries and well defined ABI breaks. The build should know what runtime versions it requires and account when searching Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D109885/new/ https://reviews.llvm.org/D109885 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
