ICEs, libc6, yp
Hello,
I'm getting some wierd non-reproducible ICEs while building big
packages. glib 1.2.5 built out-of-box, and gtk built its main packages
and then ICEd while building libgtk1.2-dbg in the second pass. I
duplicated the compile command and no ICE. Oh well, can't bug report.
So then I tried building mozilla (okay, so I'm ambitious :-), and it
ICEd in the middle too. On a whim I left it to build again overnight,
and it all built flawlessly (but didn't run- opened a blank window and
never put anything in it). Now I'm trying again to build gtk... I see
it just passed the point where it ICEd earlier. (BTW, gnome-libs builds
out-of-box!)
The question is, are intermittent non-reproducible ICEs to be expected
on this platform? What might this mean for autobuilding- especially of
big packages; or is ARM not yet at the level of maturity where we have
an autobuilder?
This is all with gcc 2.95.2-0pre1 from the Debian mirrors.
Also, on the assertion problem with GNOME apps ("BUG IN DYNAMIC LINKER
ld.so: ... Assertion `! "unexpected dynamic reloc type"' failed!"), is
there a way I can figure out which library was not built properly? The
gnome-hello test programs all run fine, but e.g. e-conf does not. I
used ldd to check which libs each links, and e-conf links to 4 orbit
libs, libcapplet, libnsl and libgnorba, which the gnome-hellos do not.
The behavior didn't change when orbit was rebuilt/upgraded (from 0.4.92
to 0.4.95), nor for gnome-libs (1.0.10 to 1.0.40), which leaves
libcapplet (GNOME control-center) and libnsl (libc6). Panel gives the
same behavior before and after the upgrades, and does not link
libcapplet but does link libnsl.
I think the finger of blame is drifting toward libnsl. I'm also getting
this error with ssh now, which links libnsl, so I think this is it.
So the question is, is there some reason I shouldn't rebuild libc6, or
is it as straightforward as everything else? Last time I rebuilt libc6
(for RH 5.0 on Alpha), it got me in a lot of trouble, and there are
warnings in the tarball; on the other hand the Debian package system
simplifies and standardizes so much... I notice it's been a little
while since it was built for ARM (2.1.2-0pre7, current is 2.1.2-5),
resulting also in a conflict with the newest man-db; is there an
ARM-specific libc problem?
Oh, also, out-of-box, gdm just repeatedly starts the X server, changes
the background color, and crashes the X server, over and over again.
However, if you get rid of :1 in the X server line of /etc/gdm/gdm.conf,
it starts very nicely, but the default Xsession bounces me back to the
greeter, and the Debian and GNOME sessions just sit there running xrdb
forever.
Last question: is there some reason NIS doesn't work on ARM? I have
followed the same instructions for a client as on Intel (where it
worked), but keep getting YPBINDPROC_DOMAIN: Domain not bound.
Thanks very much,
-Adam P.
Reply to: