Hi, On Tue, Oct 02, 2007 at 10:09:01AM +0200, Raphael Hertzog wrote: > On Mon, 01 Oct 2007, Raphael Hertzog wrote: > > In other cases, most of the architectures are in sync and some > > special architectures are creating troubles. It looks like > > hurd-i386 is currently causing me lots of troubles for example on pango: > > http://qa.debian.org/cgi-bin/mole/seedsymbols?pkgname=libpango1.0-0
First off, many thanks for this work, I believe it is very valuable to the Hurd port (well, and Debian in general as well, of course). > > Pango export the same set of symbols across architectures but apparently > > hurd-i386 is an exception that makes my script believe otherwise. > > > > (m68k has a different md5sum too, but the same set of symbols, it's only > > the version which are different since m68k didn't manage to build the > > exact same version historically... however hurd-i386 has more symbols > > in this case, it looks like it exports symbols that should be hidden) > > Can some hurd people check and explain me why hurd-i386 libs export > private symbols ? In general, the Hurd port uses the same tools, so the most likely explanation are configure checks which mean "gnu/glibc" but actually say "linux". I'm trying to look into pango now. > Because IIRC (but I didn't check), the various "_pango*" are marked as > "hidden" with gcc's visibility attribute (same goes for the "_hb_*" and > "_HB_*" symbols). > This difference is undesirable and complicates somewhat the work of > maintainers who will have to deal with arch-specific differences when > there shouldn't be any. Agreed. Would it be easy to have a list of those libraries which differ on hurd-i386, unless it's almost every lib we're talking about anyway? I checked a couple, and it seems glib2, gtk2, and gnome-vfs2 seem to have various issues. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]