On Mon, Jan 19, 2004 at 04:44:03PM +0100, Thorsten Sauter wrote:
> * Richard Hirst <rhirst@linuxcare.com> [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.
Richard
# doesn't hurt. I guess all archs can live with this.
needed_symbols.add(("sys_siglist", 1))
+ # This is a hack to stop libm being reduced to nothing
+ # RGH.
+ needed_symbols.add(("log", 1))
# calculate what symbols are present in small_libs
present_symbols = Set()