[PATCH] D109885: [MLIR][[amdgpu-arch]][OpenMP] Remove direct dependency on /opt/rocm
Matt Arsenault via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Dec 20 12:32:02 PST 2021
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
More information about the cfe-commits
mailing list