Re: ICEs, libc6, yp
Adam C Powell IV <hazelsct@mit.edu> writes:
> 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.
For the record, I get those on my NetWinder too. Not too frequent -
but frequent enough that it interrupts some of the big package builds.
I'm not sure if this is a software problem or perhaps even a hardware
problem (I have an early (rev4) NetWinder). Possibly a different
kernel version might help.
> Also, on the assertion problem with GNOME apps ("BUG IN DYNAMIC LINKER
> ld.so: ... Assertion `! "unexpected dynamic reloc type"' failed!"),
One of the libraries was built without -fPIC.
> 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.
objdump --dynamic-reloc <library>
Make sure you don't have R_ARM_PC24 records.
> 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.
My libnsl looks OK.
> 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?
No. I just haven't felt the need to rebuild it lately.
Rebuilding should be as easy as "debian/rules binary" after you've
unpacked the source using "dpkg-source -x". (Actually, for glibc, you
need to have the kernel headers unpacked and installed into the proper
place too)
> 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.
Um, I don't know. I've never tried gdm. I know the X packages
definitely need some work. However, I don't even have my NetWinder
plugged into a monitor. I got X to build cleanly - but that doesn't
mean it runs all that cleanly.
> 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.
I haven't tried NIS on ARM either.
Cheers,
- Jim
Reply to: