Bug#791485: symbols file: arch-bits=32|64 vs subst
On Tuesday 15 September 2015 16:58:36 you wrote:
> Hi Lisandro,
>
> On Tue, Sep 15, 2015 at 3:50 PM, Lisandro Damián Nicanor Pérez
>
> <perezmeyer@gmail.com> wrote:
> > tag 791485 wontfix
> > thanks
> >
> > tl;dr: we still need to support qt4' qreal.
> >
> > On Tuesday 15 September 2015 15:13:29 Mathieu Malaterre wrote:
> >> Hi,
> >>
> >> [For some reason I never received your -submitter@b.d.o email]
> >
> > Sometimes mails get lost, it also happens to me from time to time.
> >
> >> > For what I understand of your bug report arch-bits it's simply 32 or
> >> > 64.
> >> > The problem is that it's not as simple as that. There are differences
> >> > between archs that use the same amount of bits.
> >> :
> >> :q!
> >>
> >> Could you name a single example in Debian archs ?
> >>
> >> Thx much.
> >
> > Take a look at <https://wiki.debian.org/ArchitectureSpecificsMemo>, first
> > table.
>
> Good. I see that sizeof (void*) is either 4 or 8 (which is how I
> understand `arch-bits` implementation)
>
> > An example was s390 and s390x which share the size of some types, like
> > size_t. While s390 is no longer a release arch it makes an example of
> > something that might happen again. So yes, we can now say this is a
> > storical reason, but was valid for quite some time.
> >
> > See the full table of conversions in:
> > pkg-kde-tools/perllib/Debian/PkgKde/SymbolsHelper/Substs/TypeSubst.pm
>
> As per my original post, I never said I wanted `subst` behavior. I
> said I wanted a merge mechanism based on `arch-bits`.
And that's the big difference here, we do **want** to keep the subst method.
> > Another offender is qreal for qt4 apps, which we still need to support,
> > and so we need to keep this until we get rid of qt4... if we ever do.
>
> That's KDE-specific. There is no such thing as qreal in C++.
And pkg-kde-tools it's a pkg-kde's tool, so it needs to support pkg-kde's
needs, like subst.
> > And if we do change this we would need to fix tons of packages...
>
> Sorry failed to understand you.
We would need to redo symbols files to drop subst in favor of something else.
> > My suggestion is to really try to get a symbols generator directly in
> > dpkg. I would keep the possibility of not depending just on the arch-bits
> > because history has shown us that exceptions might happen. But that's up
> > to the implementer... until a new arch arrives ;)
>
> Ok. I've totally failed to follow you.
>
> Here is a simple one liner from dpkg-gensymbols file. The man page states:
>
> [...]
> The architecture-bits is either 32 or 64.
>
> (arch-bits=32)a_32bit_specific_symbol@Base 1.0
> (arch-bits=64)a_64bit_specific_symbol@Base 1.0
> [...]
>
> This is a strict *or*. As per my understanding one said arch is either
> `arch-bits=32` or `arch-bits=32`.
And a problematic solution. This means the same API entry gets two lines in
the symbols file. This makes diffing a nightmare. Moreover keeping extra
linkages like we do for private stuff in the qt5 stuff also problematic, as we
would need to keep track of two symbols for the same api.
With the subst method this becomes much easier, as the same API entry becomes
the same entry in the symbols file.
> So you are saying that for a said `arch-bits` (let's say 32) with a
> particular said function, you are saying the symbols for this C or C++
> function will be different on another `arch-bits=32` ? Could you
> please take me by the hand and show me such function (C or C++, no KDE
> typedef please) ?
I do remember having to patch pkg-kde-tools due to exactly that problem. But I
must admit I can't find an example now, a lot has happened since those days.
Modestas would have probably know better, he wrote the tool, but sadly he is
not active anymore. Maybe Sune?
And no, Qt/KDE specific stuff should remain, that's why the tool is a team's
tool. And that's why I'm suggesting you that if you want changes to happen,
make them happen in dpkg.
I really hope that makes things clearer :) I still owe you an example, I just
need to dig further.
--
14: Para acceder y navegar en internet
* Debe tener conexion a Internet
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/
Reply to: