New Base for symbols in Qt5.6

[Lisandro Damián Nicanor Pérez Meyer]

On Sunday 27 December 2015 15:43:59 Dmitry Shachnev wrote:
> Hi Lisandro,
[snip]
> My script (debian/scripts/migrate-symbols.py in qt56-symbols branch) is
> *much* smarter than plain sed -i 's/@Base/@Qt_5/g'.

I have no doubt in that. My intention wasn't to check your branch but to check 
if the change in the version node [0] from Base to Qt_5 would make apps 
compiled against Qt 5.5 fail to be linked against Qt 5.6. Good news is that 
everything still works.

[0] <http://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_25.html>

On a side note this feature is analogous to what our symbols files do [1]. But 
that doesn't means we should drop symbols files ;)

[1] <https://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html>

> 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 was talking about the upstream change in symbols' nodes :)

But let me check the branch (done, see below).

> 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 an example of such a case? The script was being run over private 
headers only, so even pointers to private functions should be private.

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

Forget that, I mixed stuff. The symbols are marked as private by using a list 
created by syncqt.pl, so things should be fine.

> 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?

I'm totally for it. If it becomes a problem for someone we can consider 
generating a new binary package from the same source and adding the python 
dependency there. We might even do that from the beginning.

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

And of course I'll be AFK tomorrow, maybe come back online late on ARST's 
night. Gah, timezone are hard for us :)

OK, I've checked the branch and I merged it to experimental. Please do not 
forget to add the proper copyright headers to the scripts.

Should we keep the merging script? I think having it on git's story should be 
enough. I also don't mind shipping it once in the packages.

-- 
15: Que es el "Correo Electronico"
    * El correo que te llega por la corriente
    Damian Nadales
    http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20151227/91bd9974/attachment.sig>