From the top of my head I remember that we had problems with the results in one product as the debug information created by gcc was sometimes not quite correct so we got false positives.
Would you like to reduce or even avoid the dependency on DWARF debug information then?
The implementation of abi-compliance-checker is fragile as it relies on parsing output from readelf etc. Also, it loads the full data into RAM so huge packages like libreoffice can make it run OOM.
Are there any more software development challenges to consider?
A fundamental problem with only looking at the debug information is that one can't know whether a symbol or structure is part of a public or private API. So some libraries produce false positives. The abi-compliance-checker author also offers a method to evaluate the public headers in order to filter out private symbols. That requires recompiling the software though which is not so straight forward to do in a review bot.
Does such information point any details out which are interesting for further consideration?
The reports abi-compliance-checker creates are quite nice though.
Are there any plans to integrate such tools into the Open Build Service in a more convenient way?
How similar are the involved data structures (or XML data type definitions/schemas)?
I didn't look into libabigail so I can't tell.
How do you think about to improve the desired clarification of software dependencies by a discussion of a topic like fine-tuning for data structure designs? Regards, Markus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org