Re: the [de]register_frame_info definitions issues on Alpha

[Loic Prylli <Loic.Prylli@ens-lyon.fr>]

H.J. Lu writes:
 > >  > [CC to HLU]
 > >  > 
 > >  > Loic Prylli writes:
 > >  >  > I have tried the gdb from (Mikolaj J. Habryn) and got the following
 > >  >  > error:
 > >  >  > 
 > >  >  > ./gdb: error in loading shared libraries
 > >  >  > : undefined symbol: __deregister_frame_info
 > 
 > Which libc are you using?
 > 
 > # nm /lib/libc-2.0.7.so | grep __deregister_frame_info
 > 0008ba58 T __deregister_frame_info
 > # objdump --dynamic-sym /usr/bin/gcc | grep __deregister_frame_info
 > 08048ca4      DF *UND*  000000a8 __deregister_frame_info
 > 
 > You should use the latest glibc 2.0/2.1 from CVS and compile it with
 > egcs 1.1.1/Linux.
 > 

Hello again,

I know what libc to use to solve my problem. You miss my point, I have 
an up-to-date libc on a system that works perfectly with any
executable. I am speaking of problems with systems that do _not_ have
a libc compiled with the linux/egcs.

But I do not see why to break binary
compatibility _gratuituously_, there is a need to transfer binary
executables to systems which may not have the latest glibc 2.0/2.1 
compiled with egcs1.1.1 with Linux specific patchs. I want people to
be forced to upgrade their libc, only if I can find a reasonable
explanation for the fact that new features in C++ handling must break
binary compatibility of C-only program (and I know
backwards-compatibility is preserved in the present case , that's not
the point here). 

In summary, I know I can use the latest glibc 2.0/2.1 from CVS and
compile it with egcs 1.1.1/Linux, but I do not _want_ to be forced to, 
it introduces unecessary requirements in the way systems are
upgraded, and in the circulation of binaries between systems.

Regards,

Loic