On Mon, Jan 19, 2004 at 08:35:11PM +0100, Thorsten Sauter wrote: > * Richard Hirst <[EMAIL PROTECTED]> [2004-01-19 18:30]: > | On Mon, Jan 19, 2004 at 04:44:03PM +0100, Thorsten Sauter wrote: > | > * Richard Hirst <[EMAIL PROTECTED]> [2004-01-18 20:48]: > | > | Initial boot fails due to a SEGV in frontend; this appears to be because > | > | of a bug in glibc, triggered by libm being reduced to what is effectively > | > | an empty library. Bug #228375 filed. I hacked mklibs to include a symbol > | > | from libm, so I could build a working image. text frontend worked ok. > | > | > | > | Kernel hung on reboot when discover tried to load de4x5.o; the kernel > | > | has the tulip driver compiled in to handle the network i/f. I renamed > | > | the module and tried again. This time it rebooted ok, and base-config > | > | ran ok. > | > > | > > | > very good news. > | > mklibs is a little bit mystic for me. :-) > | > > | > Should I include this patch on paer as long as we have no updated mklibs > | > version? > | > | Hmm, the patch is below, but I can't say whether you should hack > | /usr/bin/mklibs on paer. Carlos (hppa glibc guy) agrees that I found > | the bug in glibc, but he is fixing it in a slightly different way. I'd > | assumed that we would get a fixed glibc, rather than work round it in > | mklibs, but I guess a new mklibs is easier to arange. "log" was just a > | symbol I picked at random; the requirement is that "objdump -p libm.so.6" > | shows a non-zero DT_JMPREL value. As "log" adds about 50K to libm, I > | suspect other archs would be upset by this mklibs change. > > > of course, not hacking the system mklibs binary, but I could use my own > mklibs app as long as we have no fixed glibc and/or mklibs package. This > will make the images working for this time.
Sorry, misunderstood. Yes, that makes sense. Thanks, Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
