Re: popen & pclose; How to report platform-specific bugs?
email@example.com (Konstantinos Margaritis) writes:
> things went back to normal after I replaced with the old (2.91.58)
> libstdc++. I believe it has to do with the fact that the libc I'm using
> (2.0.100-2) is not quite fully 2.1-compliant, and some symbols don't have
> GLIBC2.1 versions. Of course, I maybe wrong...
I've seen similar problems with xpm4g. It seems that some packages are being
built on system that has a glibc newer than anything available in a released
package. Either that or I'm somehow missing a glibc upgrade (I have something
called "libc6 2.0.100-2" installed: am I correct in believing that this is the
most recent one available?).
I wouldn't expect to see a new libc6 package until after glibc-2.1 is fully
released, but I wouldn't expect to see packages compiled against an unreleased
libc either. Here's a more general question: how do I find out where these
packages are coming from, to send the builder a note about the problem? (I'm
new to Debian, so be gentle if I'm missing something really obvious). I know
there is a "Maintainer:" field in `dpkg-deb --info xpm4g_4.5j-0.8.deb`, but I
also know that this name may be the overall maintainer and not necessarily the
person who built/uploaded the powerpc package. I can look at the latest entry
in /usr/doc/xpm4g/changelog.Debian.gz, but is that changelog updated when a
package is rebuilt without source changes on a new architecture? The .debs are
signed somehow, right? Can I get at that signature? How do I find out who to
A note from Hartmut earlier suggests to me that many ppc packages may be
autobuilt on a single machine. Is there a way to make sure that such a machine
isn't building packages against an unreleased C library?
PS: re: emacs, I had problems with prepackaged emacs 20.3-6 and 20.3-7, the
floating point thing looked like a likely culprit. (I've backed out to 20.3-5,
which works find except for 'movemail' always failing, had to replace it with
my own copy). Something I read suggested that emacs might have determined the
endianness wrong and some data representations were messed up because of
it. Anyway I think those packages were available well before the recent
upgrade to egcs, so the problem is probably older than the compiler. I'll see
if I can figure out enough of the debian source-package setup to download the
diffs being used and compile a test version this weekend. I've got my own set
of ppc-specific patches for emacs that I know work; I'll compare mine to those
in the source package and see what the differences are.