New Base for symbols in Qt5.6

[Dmitry Shachnev]

Hi Lisandro,

On Sun, Dec 27, 2015 at 02:22:20AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> Now we feared that this change would create us problems with loading apps
> compiled against older versions of Qt. In order to test this I built qtbase
> 5.6 beta with this changes:
>
> - sed -i 's/@Base/@Qt_5/g'  # yes, private symbols would get this wrong.
> - Build qtbase and get symbols changes.
> - Process them with pkgkde's symbolshelper. In this step private symbols will
> get corrected by marking as missing the @Base versions and "new ones"
> appearing with @QT5_PRIVATE in them.
> - Build again this time succesfully getting the binary packages.
> - On a VM I installed both an app I compiled with Qt 5.5 and hexalate, which
> only require stuff present in qtbase and qt5.6~beta's qtbase5-dev and
> dependencies.
> - ssh -X the VM and run them both without issues.

My script (debian/scripts/migrate-symbols.py in qt56-symbols branch) is *much*
smarter than plain sed -i 's/@Base/@Qt_5/g'. Its algorithm is:

1. Get the list of symbols in new libraries based on the build log.

2. For each symbol in the symbols file, check if that symbol exists in the
   new libraries.

   - If it exists, changes the version part of the symbol to Qt_5 or
     Qt_5_PRIVATE_API, depending on what's found in the new library.

   - If it doesn't exist, leaves it unchanged (maybe the symbol is for
     another architecture) so that we can process it the usual symbolshelper-
     based way.

3. For each old symbol that has disappeared, and is not optional or private,
   warns that it is removed. For qtbase its output is:
   http://paste.debian.net/355955/

And yes, changing the version part of the symbols does not break the ABI,
however removing the old symbols does (so we need to be careful).

> So I think it's safe to go ahead with the changes.

So are you OK with merging my branch? :)

I have just updated it based on i386 build log.

> Dmitry: we still need to look for private symbols as we used to, IIRC there
> where some cases of upstream not marking private symbols as such. having both
> methods at hand will surely catch those cases.

However I also know that our current algorithm has some false positives —
i.e. it marks functions using *pointers* to private objects as private, even
if they are part of public API. I thought that by fully switching to upstream
algorithms, we will get rid of that bug.

Do you have any examples of "upstream not marking private symbols as such"?

In any case I think we should keep the logic in pkg-kde-tools package, i.e.
replace the existing script with mine or extend its logic. I hope Python
dependency is not a problem, is it?

P.S. I will be offline most of today, will be able to look at anything only
tomorrow (MSK time).

--
Dmitry Shachnev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20151227/bcc1a1ff/attachment.sig>