Hello! Sorry for my late response. I've been through a few personal things lately, and thus I haven't had time to deal with this.
I was unfortunately not aware that there would be such an ABI breakage as I didn't previously realized even changing public strings could cause an ABI break. I assume it could be fine if any program does not rely on the size information, but either way, I think deprecating these symbols would be a good way to move forward as I think there are better solutions available. Looking further at the report, I hope the impact should be negligible considering this is just version information. Then again, I'm not too sure of any programs that rely on either of those variables, and since this isn't impacting the main functionality of the library, I think it should be okay to keep the ABI version the same. Since other distributions, such as Fedora since version 40, have adopted our version of libmad, and I do not see any attention to this problem nor have received any prior reports (publicly or privately), I believe that in practice, this ABI breakage should have a minimal impact. If you see any program that relies on any of the symbols that report this version information, then please be sure to let me know so we can come up with a solution. Otherwise, I think it should hopefully be acceptable in this situation given it's predicted minimal impact. Despite all that, I do apologize for unintentionally breaking the ABI between 0.15.1b and our fork. It is aimed to keep major versions, including all 0.16.x versions, ABI compatible with one another. --- Auf Codeberg.org ansehen ( https://codeberg.org/tenacityteam/libmad/issues/20#issuecomment-10184736 ). Codeberg e.V. – Arminiusstraße 2-4 – 10551 Berlin – Germany Registered at registration court Amtsgericht Charlottenburg VR36929.
