[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libc6 needs >= 2.0.7u (Closes: dpkg-shlibdeps is too strict



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?

> 
> > All grumbling asside, the only way I can see to deal with a range of
> > conflicts is to express each version conflict explicitly. This yields the
> > following conflict entries:
> > 
> > libstdc++2.8 (=2.90.29-1), libstdc++2.9 (=2.91.58), libstdc++2.9 (=2.91.59)
> > 
> > Does this work for everyone?
> 
> These won't work, especially the libstdc++2.9 ones (the versions you
> mention never existed, you must provide the debian revision too). I think
> what the 2.0.7u-7.1 NMU has changed was the best.
> 
This is the first I have heard of an NMU! It was my understanding that
such things were done when the maintainer was either unable or unwilling
to make the desired changes. That is certainly not the case, as I have
been pleading with this group to tell me what the conflicts are supposed
to be to fix this problem ever since it was pointed out that the dpkg
conflicts were not correct.

If someone...anyone...will provide the correct Conflicts line I am more
than happy to make the corrections and provide an upload.

If there is some desire to have a different maintainer than myself on this
package you have my complete support. Step up to the plate an take over,
because I have had it with the kind of "help" I have recieved over this
problem.

Just tell me straight...OK?

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: