On Wed, 2022-01-12 at 21:06 +0100, Maxime Chambonnet wrote: > > > Headers and libraries should installed under the standard path, > > so that the compiler and linker should be able to find them without > > additional flags. Just install all stuff to /usr should be enough. > Currently for example rocm-hipamd installs to /usr/hip, and > lintian yells a lot. All to /usr is quite not clear enough.
Then it sounds like that the upstream CMake installation targets are primarily written for somewhere like /opt instead of /usr. I looked into one Gentoo ebuild for ROCm and the problem is rather distinct. https://github.com/gentoo/gentoo/blob/2ed748a3b6412f99bc249e089e9221e38417a8f8/dev-util/hip/hip-4.1.0.ebuild If shlibs are installed to somewhere like /usr/lib/rocm/lib/, we are still able to tamper with ld.so.conf. If binary executables are installed to /usr/lib/rocm/bin/, then we are screwing up with the default shell PATH. This is a deadend because we are not going to patch all POSIX and non-POSIX shell configs. Neither do we introduce weird scripts for the user to source. Standarlizing the upstream install target is inevitable to some extent. A flag can be introduced for the upstream cmake file along with some code, which by default install things to /usr/local like most other existing software. > > > > > I did not understand this question. Do you mean something like > > /usr/lib/rocm-{4.5.2,5.0.0}, > > or > > /usr/lib/rocm-4.5.2/llvm ? > Rather the first, not sure I see a difference, in all cases, it looks > nested under "rocm-something" to me. And we further down agree > that nested is probably not the way. Yes. We should just stay away from nesting things. > > How are these files read by ROCm? Is there anything like > > "PYTHONPATH" for the gpu code files? We should choose a > > supported path compatible to debian policy. > There is a cmake flag / environment variable for now, > HIP_DEVICE_LIB_PATH :< > The current preferred layout is /usr/amdgcn/*.bc Anything like /usr/share/amdgcn/ (in case they are arch-indep) or [/usr/lib/amdgcn, /var/lib/amdgcm, /var/cache/amdgcn] (in ase they are arch-dep) could be better. > > BTW, are these files architecture-independent? Namely, > > can arm64 and amd64 produce the exactly the same (e.g. > > md5sum-identical) output? > I don't know, we discussed it last jitsi meeting and > I believe that no one tried yet :) Then we regard them as architecture-dependent for initial debian packaging. I looked around in the Gentoo ebuild repository, https://github.com/gentoo/gentoo/search?q=hip&type=commits https://github.com/gentoo/gentoo/search?q=rocm&type=commits from which we can borrow a lot. Namely, starting from scratch by ourselves is not necessary. > >