amdgcn/bitcodes relocation for distributions

[emollier]

Greetings,

While attempting to package rocm-device-libs for the debian project, I noticed amdgcn/bitcodes landed straight into $PREFIX/amdgcn. From an operating system perspective, since this is causing installation below /usr/amdgcn which is not conformant to FHS, I had to shift the directory a bit by applying this patch on Salsa to move to /usr/share/amdgcn.

Would such change be of interest on your side? Do you foresee any issue if bitcodes are moved around this way, and if so have a more appropriate approach to suggest? I'm afraid my patching could be rather naive at the moment.

Thank you for making ROCm freely available!

Have a nice day, :)\ Étienne.

PS: my rationale for using /usr/share is that the produced bitcodes turn out to be CPU architecture independent data, but I'm also fine with /usr/lib/amdgcn (as long as it is not /usr/lib/$TRIPLET/amdgcn, the $TRIPLET would force us to make a set of architecture dependent packages instead of one all package, so not ideal from my point of view).

[b-sumner]

Hello @emollier, and thanks for bringing this up. We are aiming to change the location of these libraries and have included external discussion. These libraries properly belong in the LLVM/clang resource directory and we will likely move them there.

[emollier]

Hi b-sumner,

Thank you for the clarification. So this is a temporary workaround and will see how things evolve in upcoming ROCm versions.

Have a nice day, :) Étienne.

[Mystro256]

Hi @emollier,

I have been working with @t-tye, and an engineer is currently working on fixing the installation path as @b-sumner mentioned. Once the patch has been pushed to amd-stg-open, I will try to remember to update this ticket, so you can cherry-pick it as a Debian quilt patch.

I spoke with the senior technical leads, and my impression is that this:

the produced bitcodes turn out to be CPU architecture independent data

Is not strictly true and should not be assumed. For best results, you need to strongly tie the device-libs, llvm, and clang version together. The "LLVM/clang resource directory" that @b-sumner mentioned is likely /usr/lib/llvm-13/lib/clang/13.0.1/lib/ in Debian, e.g. see the libclang-common-13-dev package.

I would advise that you talk with the LLVM and Clang Debian maintainers, so you can co-ordinate with them effectively.

Thanks/Merci!

[emollier]

Hi Jeremy,

Thanks for considering sharing the patch!

Thanks also for the warning, I made the necessary adjustments so the current quilt patch 1 points to an architecture dependent location, and eventually allows for proper multiarchitecture support; this is currently /usr/lib/$TRIPLET/amdgcn, but can be adjusted more easily than the Architecture: all/any flag.

Debian LLVM Maintainers are also pinged for coordination if need be 2.

Have a nice day, :) -- Étienne Mollier @.***> Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity. On air: The Gift - Tuesday's Child

[b-sumner]

Closing this as part of an old issue cleanup. Please open a new issue with any remaining or new concerns.