Re: Troubles with rocm-compilersupport/5.6+git20231212.4510c28-1~exp1
On 2024-01-21 10:59, Christian Kastner wrote:
>> 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.
>
> This is a tricky one, but I *think* it should be OK to just bump the symbol.
> This would break current users of amd_comgr_get_isa_count@amd_comgr_1.8
> but since the ABI has changed, current users would be broken anyway, right?
Please disregard the above, as I misunderstood the original problem. I
had another symbol versioning problem in mind.
I've checked the sources this time, and now understand what you meant.
Just restating your findings to confirm that I've landed on the same
page: our initial version has
@1_8 {
global: amd_comgr_get_isa_count
}
@2_0 {
global: amd_comgr_get_isa_count
}
This results in (only) amd_comgr_get_isa_count@1_8 being exported by our
library.
The @1_8 entry was erroneously left over after the bump, so upstream
removed it in the meantime, resulting in upstream exporting
amd_comgr_get_isa_count@2_0 -- and this is where we go apart.
(Incidentally, although I didn't dive all too deeply, I did not manage
to find what ABI breaking change was introduced in 2.0. This function
seems to just produce the count of elements in an iterable.)
On 2024-01-15 23:16, Cordell Bloor wrote:
> 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.
This would also have been my approach to this.
This has been addressed in the RFS, so I'll continue in that thread.
Best,
Christian
Reply to: