Raphael Hertzog a écrit : > 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.
Except that the problem appearing only on unofficial architectures, mole provide a common symbols file. That is where the problem lies. >>> 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. Even if the bug is present in all architectures, its effects are only visible on armel. And maintainers do not care about unofficial architectures, so the package will simply FTBFS. > 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. libtool is buggy, and that is even more true for older versions. And if you look at the archive, you will see that most of libraries use an old libtool version. The library has to fixed, but the job of porters is not to fix general problems with libraries, we already have a lot of work to do in other domains. But if porters doesn't fix this, the maintainer will simply ignore the problem, even if a bug report is sent. Just have a look to the following URL and see how many libtool bugs are ignored for a very long time: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=kfreebsd;[EMAIL PROTECTED];pri0=pending:pending,forwarded,pending-fixed,fixed;ttl0=Outstanding,Forwarded,Pending%20Upload,Fixed%20in%20NMU;pri1=pending%3dpending%2btag%3dwontfix,pending%3dpending%2btag%3dmoreinfo,pending%3dpending%2btag%3dpatch,pending%3dpending%2btag%3dconfirmed,pending%3dpending;ttl1=Will%20Not%20Fix,More%20information%20needed,Patch%20Available,Confirmed,Unclassified;ord1=2,3,4,1,0,5 >>> 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. I totally agree it's better to fail in such cases, but it is better to fails on all architectures, so that the problem is not just ignored. -- .''`. 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]
