On Tue, 20 Nov 2007, Aurelien Jarno wrote: > > 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 which case it doesn't make sense to have a common symbols file and the problem is solved. > > 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 In turn this is caused by a bug in libtool because that symbol should never have been exported on any arch... and on armel gcc was doing the right thing by "inlining" the function properly. So the initial problem is not armel-specific and I fail to see why we should ignore it when this failure enabled us to discover a bug in libtool. And if you want a permanent work-around, I already suggested the environment variable. I haven't seen any other better alternative yet. > > 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. Because of a bug in libtool. I fail to see why we should be more lax just because libtool has bugs. > > 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. Yes, but that's not something I control. In fact, if that's what you want, it's better to fail so that we can report problems to maintainers who will then prod upstream to implement a version script or similar. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
