[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Troubles with rocm-compilersupport/5.6+git20231212.4510c28-1~exp1



Hi folks,

I've pushed some updates to rocm-compilersupport on salsa. However, there are three issues that are blocking me from submitting an RFS.

1. Code Object V3 has been deprecated in LLVM, so sample COV3 binaries were checked in to the comgr repo to ensure the loader could still be tested once support is removed [1]. These binaries were generated from the sources in the repository. I don't think this is a DFSG issue because the binaries could be built from the sources in the tarball. Nevertheless, I'm thinking that perhaps I should repack the tarball to remove the binaries and patch comgr to continue to build the test data from source.

2. The amd_comgr_get_isa_count function was exported with the wrong version in libamd_comgr2. The ABI of amd_comgr_get_isa_count was changed in 2.0, so it was supposed to added to the amd_comgr@2_0 symbol list and removed from the amd_comgr@1_8 symbol list. However, it was not removed, so it was (incorrectly) marked as amd_comgr@1_8 in comgr 2.0. Later, the duplicate was removed [2] and the symbol was therefore changed from amd_comgr@1_8 to amd_comgr@2_0. I've reverted the removal, but that will leave Debian's ABI inconsistent with upstream.

The real mistake was back when comgr was bumped to 2.0, and arguably the removal of the wrong symbol is merely a bugfix that brings the actual ABI in line with the original intention. However, this is still quite unfortunate. I suppose maybe we could add both symbols? I'm not familiar with the exportmap that is used for the symbol versioning here, but perhaps there's a good way add an alias that handles this.

3. There's a few lines of code in the build file that have been included from a project with no license. The root build file is a rather annoying place to have such a problem, but I will probably repack the tarball to omit that code. The questionable code isn't useful for Debian in building the package anyway.

If you have any thoughts on these issues, I would certainly appreciate advice from more experienced maintainers.

Sincerely,
Cory Bloor

[1]: https://github.com/ROCm/ROCm-CompilerSupport/commit/3c51531db0939006f589cecf01f748361f151692
[2]: https://github.com/ROCm/ROCm-CompilerSupport/commit/af5b350b41bd8e7902d57b74531d2dcab6c1f921
[3]: https://salsa.debian.org/rocm-team/rocm-compilersupport/-/blob/upstream/5.6+git20231212.4510c28/lib/comgr/CMakeLists.txt#L6-26


Reply to: