Raphael Hertzog a écrit : > On Tue, 20 Nov 2007, Aurelien Jarno wrote: >>> Though it's worth asking ourselves if it would make sense to have an >>> intermediary fallback between debian/*.symbols.<arch> and debian/*.symbols >>> that >>> would be debian/*.symbols.<kernel>. >> While it will fixes the problem due to the variation of the ABI across >> kernels, I am not sure that is the problem we will see the most. The >> most problematic variations, will happens on the same kernel, as it >> could be seen from bugs #441736, #429600 or #342084. > > Riku said in #441736: > "This is the same bug as on unixodbc, #429600, #342084." > > The issue is that some supplementary symbols are exported due to libtool > working differently with C++ libs for apparently no good reasons. It is not > really armel-specific (except for the fact that armel generated > supplementary symbols that should be not exported according to the version > script).
Please read the bug log again. The supplementary symbols are not the same on the different architectures, which causes some architectures to have missing symbols compared to some others. > In any case, having new symbols as is the case in those reports will not > generate a failure with the default behaviour of dpkg-gensymbols unless > the maintainer want those failures. Wrong. Some symbols are "missing" on armel: Error: incorrect soname libodbcinstQ.so.1, missing symbol: Base QGList::count() const > So it's still not representative of failures that we're likely to get due > to dpkg-gensymbols (unless many maintainers decide to increase the level > of checks, which I doubt. Furthermore maintainers that do that are likely > reactive maintainer that will quickly integrate changes needed for > unofficial architectures). As explained, it would have also failed on armel without increasing the level of checks. > That said, we might want to have the possibility to flag private symbols > in symbols file and have a mode where the disparition of private symbols > doesn't cause a failure. Not sure about it. That is not a correct solution. If you are able to list private symbols, better not export them instead of flagging them. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `- people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
