[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: more __register_frame_info problems [Was: Re: fwd: Debian sparc32 on Ultra status report (also status of debian-sparc)]

"Marcelo E. Magallon" <mmagallo@efis.ucr.ac.cr> writes:

> [ This is crossposted to -sparc and -ultralinux ; trim as needed ]
> First of all... with BIG friendly letters... DON'T PANIC!
> On Mon, Dec 14, 1998 at 07:37:06PM -0500, Steve Dunham wrote:
> > BTW, Ultrapenguin now has a broken libc - they added the
> > register_frame_info bug for Red Hat compatibility - also the
> > sparc-linux Netscape doesn't run on Debian, probably a libstdc++/glibc
> > problem - the sparc-sunos one does work.  (Maybe if I pull the
> > libraries from RedHat 5.2 and use a LD_LIBRARY_PATH.)

> Uh oh... I've got to hide... fast!

> Ok. Let me get this... RH is compiling their libc with a broken compiler
> (yes, it's broken!) that makes a symbol (__register_frame_info) that's not
> intended to be there be there? And Netscape uses RH to compile its stuff?

The reference is only in the "vreg" program, the netscape binary
itself doesn't reference __register_frame_info.  I can only assume
that either they didn't use egcs to compile netscape itself or they
included libgcc.a before -lc. 

> Sparc ppl, do you have any reference as to why did Ultralinux do this? Is
> RH-i386 5.2 doing this too? Are they using egcs to compile the distribution
> now?

It was in the UltraSparc 1.1.9 announcement - for compatibility with
Red Hat 5.2.  Chances are that Red Hat will start doing this with i386
when they start using egcs.  (I assume they aren't aware of the
problem and accidentally include libframe.o in libc.so.6 when then
compile with egcs.)

> Can we *please* get in touch with s/o at Netscape *and* RH to get this fixed
> asap?

Will Red Hat fix it?  It would break many or all of the sparc binaries
in Red Hat 5.2, now that the broken library has gotten out.  (I know
Red Hat did the right thing when alerted about thier libjpeg problem,
but this is a little bigger, and it's harder to establish backwards


Reply to: