Hi all, Jeremy Newton, on 2022-07-03: > Well, if the file is installed at all, it should be in share or the clang resource directory (subpath of lib) AND not start with ".", i.e. not hidden. I can't speak for Debian, but Fedora has a policy of no hidden files in /usr. > > As well, I noticed ". hipInfo" is installed into the libdir. Is this a required file? Yes, /usr/lib/.hipInfo is one of the two files removed before installation in the filesystem tree, with /usr/bin/.hipVersion. > On July 3, 2022 7:41:55 p.m. EDT, Cordell Bloor <cgmb-deb@slerp.xyz> wrote: > >Hello everyone, > > > >The last major issue that must be resolved before HIP is easy-to-use on Debian is the matter of the .hipVersion file. As it stands, this file is not being shipped in the Debian package and users must specify --hip-version=5.0.0 explicitly in their compiler flags. > > > >The file is traditionally installed to $HIP_PATH/bin. When $HIP_PATH is /usr, this implies that the file will be stored at /usr/bin/.hipVersion. That is a problem, as the location is not compliant with the File Hierarchy Standard (FHS), which requires that architecture-independent data be stored in /usr/share. > > > >The obvious place to put the file would be /usr/share/hip/.hipVersion. However, it would not be found by clang [1], and that would undermine its purpose. There are a few options: > > > >1. We could patch clang [1] and hipvars [2] to look in /usr/share/hip/.hipVersion (or perhaps /usr/share/hip/version). It's a matter of personnal taste, but I kind of like /usr/share/hip/version. :) > >2. We could ship /usr/bin/.hipVersion as the Debian FHS relaxes the architecture-independence rule to a suggestion [3][4]. > >3. We could patch --hip-version=$HIP_VERSION_MAJOR.$HIP_VERSION_MINOR.$HIP_VERSION_PATCH directly into the hipcc call to clang. It would be pretty easy to hardcode it into hipvars [2] append it to HIPCXXFLAGS, HIPCFLAGS and HIPLDFLAGS [5]. > > > >I lean towards Option 3 in the near-term, as it works with existing versions of clang. The upstream HIP and LLVM developers may be able to find a more permanent solution. The version file is seems redundant as the necessary information is already embedded in the library binary [6][7]. Option 3 makes sense in a first time. I'll be a bit short of time this week, but may get back at patching it on week end, unless someone else beats me at it. > >Sincerely, > >Cory Bloor > > > >[1]: https://github.com/llvm/llvm-project/blob/llvmorg-14.0.6/clang/lib/Driver/ToolChains/AMDGPU.cpp#L451-L459 > >[2]: https://github.com/ROCm-Developer-Tools/HIP/blob/rocm-5.2.0/bin/hipvars.pm#L152-L159 > >[3]: "The FHS requirement that architecture-independent application-specific static files be located in |/usr/share| is relaxed to a suggestion." > >[4]: https://www.debian.org/doc/debian-policy/ch-opersys.html > >[5]: https://github.com/ROCm-Developer-Tools/HIP/blob/rocm-5.2.0/bin/hipcc.pl#L191-L193 > >[6]: https://github.com/ROCm-Developer-Tools/hipamd/blob/rocm-5.2.0/src/hiprtc/hiprtcInternal.cpp#L44-L49 > >[7]: https://github.com/ROCm-Developer-Tools/hipamd/blob/rocm-5.2.0/src/hip_context.cpp#L202-L213 Have a nice day, :) -- Étienne Mollier <emollier@emlwks999.eu> Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/3, please excuse my verbosity. On air: Skyharbor - The Constant
Attachment:
signature.asc
Description: PGP signature