C++ symbol mangling difference between arches
Hello,
it is well known that C++ symbol mangling result in different symbol
names from one architecture to the other. It means that libraries that
want to provide symbol files have to maintain one symbol file for each
architecture. To avoid this problem Modestas Vainius has written a patch
that lets you encode in a specific way the small parts in the symbol name
that vary between architecture.
You can check the patch here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=0001-Implementation-of-the-subst-tag.patch;att=1;bug=533916
The symbol name in symbols files become templates that are used at build
time to generate the correct symbol name. The part that are substituded
are delimited by curly brackets like this:
(subst)_ZN6Phonon11AudioOutput13volumeChangedE{qreal}@Base 4:4.2.0
In this specific case, the symbol is considered to be
_ZN6Phonon11AudioOutput13volumeChangedEf@Base on armel
and _ZN6Phonon11AudioOutput13volumeChangedEd@Base on other arches
because qreal is a float on armel and a double otherwise.
Here are my questions for people that are more knowledgeable than me about
C++ symbol name mangling:
- how stable are those substitution over time? and is it reasonable
to maintain a list of substitution in dpkg-dev for this purpose?
- it's probably impossible to have substitutions to cover all cases
for C++ symbol mangling... do you believe that it is possible
to have enough (stable) substitutions to cover most common cases?
(in the current patch there is ssize_t, size_t, int64_t, uint64_t,
qreal and vt=<size> for C++ virtual table offset)
- what's your opinion about this approach in general?
> 1) Does dpkg-dev provide a standard way to determine if the arch is 64bit or
> 32bit one? If not, maybe it is time to add one (e.g. arch alias)?
Not yet, see #531307.
> 2) Substitution names are quite generic in the patch although they concern
> C++ (not sure about Java though it is quite likely to be similar). Maybe
> something like {c++:ssize_t}, ..., {c++:vt=number} is a better idea, but this
> adds 4 symbols to the substitution length.
Probably a good idea, yes.
> 3) Maybe it could be useful to let external packages ship substitution
> definitions in the external files (e.g. qreal could be shipped by libqt4-dev,
> (s)size_t and (u)int64_t by libc6-dev). More flexibility though I'm not sure if
> this is worth the effort of implementation and documentation.
Difficult to tell. The answer depends largely on the answers to my above
questions.
Cheers,
--
Raphaël Hertzog
Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/
Reply to: