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

Re: libc6 dependency generation



On Fri, Sep 27, 2002 at 11:19:08AM -0400, Brian White wrote:

> > > But that still leaves the question: Why is a change from 2.2.5-4
> > > to 2.2.5-13 changing the symbol set?  I would have expected that
> > > the upstream "libc6" group would not do that on minor revision
> > > changes (i.e. 2.2.4 to 2.2.5).  Surely there is some upstream
> > > libc6 policy they follow that says, for example:

> > Please don't guess things like that.

> I'm a software programmer of considerable experience (20+ years).  I
> believe I have the ability to make educated guesses as to the design
> of various software projects.  Taking a few moments to do also means
> that I learn better as people explain the way things really are and
> why they are that way.  You should never discourage someone from
> taking initiative when it comes to learning and thinking on their
> own; they are essential skills in programming as well as life in
> general.

I'm asking you to phrase the thought differently.  "Surely there
is..."  leaves the impression that one would be stupid for consdering
doing it another way.  But system libraries rarely behave in sane or
expected ways. =)

I very much want to encourage people to learn about the magic inside
of glibc.

> > Glibc has alot of linker magic in it to permit them to fix things.
> > For example, they may restrict the ability of new programs to link
> > to a symbol but still allow old programs to call it.  They may
> > introduce some extra functionality in a call, but permit older
> > programs to still run correctly.

> Just because it can does not mean it should.  I'm not saying "it
> should not", and never have.

Again, the phrasing you gave certainly left that impression.

> However, "linker magic in it to permit them to fix things" sounds a
> lot like "we can get away with bad decisions because the linker will
> hide them".

That's exactly what it is, though - Bad decisions made in the past can
be corrected without requiring everyone to recompile.  And further,
new archs or OSs that glibc is ported to don't have carry around the
baggage.

For example, When i386-pc-gnu had its recent ABI bump, we were able to
discard everything older than GLIBC_2.2.6.

> Does libc6 have any desire to be "forward compatible" with programs
> linked against a version later than the one currently installed?
> Such would allow things like including a single package from a later
> Debian distribution without the need to upgrade the base system.

To the extent that they'd like to be bug free, sure. =) Aside from
that, I don't think so.  Ben's got more history with glibc than I do,
so he might be able to provide more details.

My sig line seems particularily appropraite to this thread...

-- 
learning from failures is nice in theory...
but in practice, it sucks :)
 - Wolfgang Jaehrling



Reply to: