Re: the [de]register_frame_info definitions issues on Alpha
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
Reply to: