On Wed, Jul 20, 2005 at 09:28:22AM -0400, David Nusinow wrote: > On Tue, Jul 19, 2005 at 09:39:23PM -0700, Brian Nelson wrote: > > Uhhhhh... no... > > http://lists.debian.org/debian-devel-announce/2005/07/msg00001.html > > It's a C++ library and the ABI changed due to being compiled with GCC > > 4.0. > > [Actually, although it's written in C++, AFAIK it only exports a C > > interface so the transition may not have been necessary. I only > > realized this yesterday though and I'm not entirely sure a > > non-transition would be safe.] > Christ, not another one. Is there any sort of automated way that we can > check for these sorts of libraries before messing things up again? I won't > be doing it again for libGLU obviously, but some sort of script or > large-scale automated check of the archive would potentially go a long way. The best heuristic I can come up with so far is dpkg -x $package tmpdir && \ grep -rE '\b(use|class|template)\b|::|#include[[:space:]]+<[a-zA-Z_/]+>' tmpdir/usr/include That may turn up false positives due to the use of common English words, but I can't think of a way it could turn up false negatives. At any rate, libGLU is still a false positive by this standard, so it really takes someone who understands the ABI stuff to examine the occurrences of these terms in each header. It also doesn't address the possible problem of packages accessing private symbols from the library. If we could get library authors/maintainers to start using gcc -Wl,--version-script,<file with list of symbols to export>, then we'd be able to use the much more reliable method of feeding the list of symbols defined in the lib to c++filt and looking for '::' in the output. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature