Re: fwd: Debian sparc32 on Ultra status report (also status of debian-sparc)
On Tue, Dec 15, 1998 at 03:53:23AM -0800, Joel Klecker wrote:
> At 19:37 -0500 1998-12-14, Steve Dunham wrote:
> >BTW, Ultrapenguin now has a broken libc - they added the
> >register_frame_info bug for Red Hat compatibility
>
> It is normal for a glibc compiled with egcs to have the
> __*_frame_info symbols, that's all the "bug" is.
Normal, yes. Correct, read on.
If I compile glibc with egcs, I get a library with those symbols included.
Now, if I compile something else with gcc, I get a binary with those symbols
unresolved (meaning that something has to provide them at run time, not
necessaryly libc). If I run the binary on a system with a egcs-compiled
libc, I'm ok. If it's gcc-compiled, I'm not. (I have intentionally avoided
mentioning hamm, slink, RH 5.1, 5.2, SuSE or any other release/distribution)
Now the question is... is this acceptable? No, it's not. Why? Because
besides linux and glibc 2 now I need an special glibc 2 or an extra library
that the dynamic linker is not aware of (because it would be a preloaded
library). I'm compiling something for glibc and it should run on *any* glibc
with the *same* soname.
I uphold egcs is broken because of this.
I'm now convinced that preloading IS NOT an acceptable solution in the long
term.
Just imagine my stupefaction the other day when I found out the UP parts in
my debian sparc installation were complaining about __register_frame_info.
Marcelo
Reply to: