Hi all, I begun to have a look at the ROCm SMI library[1]. So far I see the rocm_smi64 library now has an SOVERSION 5 upstream and the oam library is still at SOVERSION 1. With the changes in build system since our rocm-smi-lib is still at ROCm 5.2.3, and reviewing the symbols table, disregarding symbols marked optional, there is one change I spotted, that is the change of signature of the shared_mutex_init function from the following in ROCm 5.2.3: shared_mutex_t shared_mutex_init(const char *name, mode_t mode); to the following in ROCm 5.7.0: shared_mutex_t shared_mutex_init(const char *name, mode_t mode, bool retried=false); If my little understanding of the C++ is correct, the signature change with the default value applied won't break the API. What I'm not sure of however, is whether this will break the ABI. In terms of symbols table, the change looks like. - _Z17shared_mutex_initPKcj@Base 4.5.2 + _Z17shared_mutex_initPKcjb@Base 5.7.0 Or through c++filt: - shared_mutex_init(char const*, unsigned int)@Base 4.5.2 + shared_mutex_init(char const*, unsigned int, bool)@Base 5.7.0 This symbol change is leaked from the third party shared_mutex library, which has probably seen a version bump in the middle. It is present in the rocm_smi64 library, but also in the oam library which has /not/ seen an SOVERSION bump upstream. I'm not certain this symbol is supposed to be exposed by these libraries anyway, but I guess it wont hurt to be on the safe side. Is it okay if I align the rocm_smi64 SOVERSION to 5, and also bump the oam SOVERSION to, say, 2, to reflect this signature change? [1]: https://salsa.debian.org/rocm-team/rocm-smi-lib Have a nice day, :) -- .''`. Étienne Mollier <emollier@debian.org> : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `- on air: Wolverine - Again?
Attachment:
signature.asc
Description: PGP signature