Re: libc6 needs >= 2.0.7u (Closes: dpkg-shlibdeps is too strict
On Mon, 7 Dec 1998, Matthias Klose wrote:
> Dale Scheetz writes:
> > On Mon, 7 Dec 1998, Gergely Madarasz wrote:
> >
> > > On Sun, 6 Dec 1998, Dale Scheetz wrote:
> > >
> > > > I was working on two assumptions, at least one of which was incorrect.
> > > > Someone told me early on that __register_frame_info was supposed to be
> > > > supplied static by the compiler. This, I am pretty sure, is incorrect. At
> > > > least libgcc.a doesn't supply this symbol. My second assumption was that
> > >
> > > libgcc.a from egcs does.
> >
> > This agrees with my memory, and brings up several points with respect to
> > what we are planning here.
> >
> > First: There is the compatibility question of having the two compilers
> > generate different ineternals. As I understand it gcc doesn't do C++
> > "correctly" and egcs does, so the incompatibility doesn't show itself at
> > the moment.
> >
> > Second: It is my understanding that it is proper opperation for egcs to
> > provide the code for such symbols as __register_frame_info (and the
> > others) as a "static" inclusion of the code and not as a link reference
> > statisfied at runtime.
> >
> > If this is correct, then it is just as big a mistake to supply the dynamic
> > link for this code in libstdc++, as it was to supply it in libm. Once the
> > library is "fixed" and egcs supplies the code instead of a reference we
> > are going to have the same set of programs that will not run on other
> > Linux systems that we arrived at with the mistaken introduction of the
> > symbol into glibc. We will have to go through this all over again!
> >
> > Isn't it a better solution to see if egcs can be fixed now, and remove
> > such references from the libstdc++ libraries? More to the point, if those
> > routines are currently supplied in the library (libgcc.a) then there is
> > every expectation that egcs already supplies them (if they aren't already
> > supplied somewhere else first), and will produce "correct" code if the
> > libstdc++ stops providing those routines, can't we move to that regimen
> > now more easily than later?
>
> 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.
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.
Waiting is,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
Reply to: