Re: libc6 needs >= 2.0.7u (Closes: dpkg-shlibdeps is too strict
Dale Scheetz writes:
> On Mon, 7 Dec 1998, Matthias Klose wrote:
>
> > Dale Scheetz writes:
> > libstdc++ needs to be linked with -lm. On the linker command line this
> > expands to .... -lm -lgcc -lc -lgcc. So if libm does not provide the
> > __register_frame_info, then libstdc++ doesn't find the shared symbol.
> >
> My point was that since egcs provides the symbol staticly in libgcc.a,
> the intention is to static link that symbol, rather than provide a shared
> linkage symbol. Libstdc++ should not need to resolve the symbol if egcs
> does its thing correctly. Libm was not supposed to supply this symbol,
> nor is any shared library. The symbol should be resolved at compile time
> by the compiler.
The symbol is resolved at link time of the shared library. What else
should egcs do?
> This is obviously an contentious issue, since gcc fails to provide the
> symbol in its libgcc.a, while egcs does provide it. If this simply
> represents the difference in the way the two compilers impliment C++ code,
> it still creates an incompatibility problem that can only grow more
> difficult with time. If we are ever going to hope to work with both of
> these compilers in the same distribution at the same time, they are going
> to have to become a lot more compatible than it seems they are now.
No. The only thing you have to be aware is that you have to link
executables with object files containing C++ code with the correct
linker. And that's {egcc,g++} {-shared,-o}. libgcc.a is an internal
compiler library, so you cannot expect 100% compatibility with different
versions. Please give me an example, where you use the correct linker
and compatibility is still a problem.
Reply to: