Date: Thu, 09 Sep 1999 23:37:17 +0200 From: Marcel Moolenaar <marcel@scc.nl> To: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> Cc: hackers@FreeBSD.ORG Subject: Re: 32+ signals and library versions Message-ID: <37D8288D.B7BC05E2@scc.nl> References: <199909091829.WAA17127@arc.hq.cti.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Dmitrij Tejblum wrote:
>
> > Dmitrij Tejblum wrote:
> > >
> > > Other OSes started to avoid version bumps. Linux promises to not bump
> > > the libc version since glibc2.
> >
> > Yes, we now have a multitude of patches floating around for all those
> > glibc2 binaries that just won't work on glibc2.1. Instead of a simple and
> > intuitive message like "libfoo version X missing" we now seem to have
> > advanced to the Microsoft way of dealing with problems: crash and let the
> > user figure it out.
>
> FUD. Every particular compatibility problem caused by a particular
> change. Please tell which problem is caused by which change, and we all
> will remember to not make this mistake.
The most important problem is that changes are not reflected on the
outside. There are different versions with a single name. It's like having
all FreeBSD versions shipped in the same box without version info. You
simply won't know what's inside until after you bought it.
From your words: if you don't change an existing library, but provide an
alternative, then compatibility isn't in danger.
> (FWIW, even bugfixes that in theory don't require even minor version
> bumps, are known to cause compatibility problems.
We should have learned from using cvs that revision information can be
crucial in determining what causes a problem. Why not extend that to shared
objects?
> It is amusing that a less popular OS (NetBSD) cares about compatibility
> more than a more popular OS (FreeBSD).
Yeah, right...
> > > > > Linker knows it. If some function ("new implementation") is missing, linker print
> > > > > an error message. This is all you need.
> > > >
> > > > I strongly disagree. Spitting "unresolved references" is *not* a way to
> > > > tell the user that he doesn't have the right libraries.
> > >
> > > I strongly disagree. This is much better than version bump. After all,
> > > we can add suggestion to upgrade libraries to the "unresolved references"
> > > message.
> >
> > I hope not, because not all unresolved references are due to library
> > version mismatches. Adding such a suggestion is just plain silly.
> > Complicating the semantic meaning of an otherwise clear and simple message
> > is not the solution.
>
> Actually, almost all such messages from rtld are due to library version
> mismatches.
Sure, but rtld is not the only player here.
> > > Then, if an user don't have right libraries, it is his mistake.
> >
> > Wrong. You expect the user to know which libraries are required by all his
> > binaries. He doesn't care (and right he is). You also don't want a
> > situation in which every application ships his own version of libraries.
> > That's a good way to destroy a working configuration (again, just look at
> > Microsoft).
>
> It is other way around. I don't want half of FreeBSD binaries linked
> with libc.so.3 and half is linked with libc.so.4.
Recompile. You have the sources.
> I don't want users to
> care which libc is required for his binaries. I don't want every
> application is shipped with the version of libc the application want. I
> want one libc (latest) to work with all binaries correctly.
See your vfork example. What you want does not seem to be in sync with what
you have experienced.
> I claim it
> is desirable, technically possible and not that difficult. (Just as a
> related example: one kernel support all binaries, why libc should be
> different?)
The difference is that a library is a static object, while a kernel
actively maintains that compatibility. There's code involved to do that.
Something a library can't handle for itself. And that's precisely why you
need versioning: to assist in maintaining compatibility.
> > > Also, we are not discussing _this_. A lot of functions were added to libc
> > > without a version bump, and it is a standard accepted practice (Just from
> > > top of my head: strlcpy, strlcat, mkstemps, strsignal, fseeko, ftello,
> > > poll, nanosleep, pread, pwrite, kld*, ... ouch, there is a lot of
> > > other functions).
> >
> > I'm not adding functions, I'm changing a well known and frequently used
> > datatype.
>
> Uhh. There is two different points:
> (1) You should not bump library version when you add new function (or
> do a non-interface change).
That depends on the versioning scheme/policy in use.
> (2) Other changes, in particular the sigset_t changes, can/should be done
> by just adding new functions.
No. That's something you can do on the syscall level, but it's not
desirable to have well known functions called differently simply because
you don't want a version bump. Priorities!
> All your previous arguments are arguments against (1), right? I still hope
> to start discuss (2)...
Please read my previous posting more carefully then. I explained why you
can not simply add new functions and claim everything is dandy.
> > > My suggestion have more serious disadvantages. For one, it add more
> > > work to you (the person who change an interface). But it save some work
> > > to everyone who will ever upgrade FreeBSD or deal with a 3rd party
> > > software. Then, say, dlsym(,"setjmp") will give probably incorrect result.
> > > But "you cannot have everything" and noone, I hope, will use such dlsym.
> >
> > Your suggestion has more impact than that. It violates POLA. In all case a
> > certain function is called `foo' except in the library where it resides,
> > where it is called `bar'. I can imagine programmers to get really confused
> > when their linker starts complaining about function `bar' and they simply
> > can't find a reference to `bar' in their entire code base.
>
> I didn't invent the idea. NetBSD do it for a long time.
I don't care who invented the idea. We're discussing this and we both have
our opinions on this matter. The fact that NetBSD uses it for some time
doesn't make it right.
> Seriously, I am a programmer and I will not be
> confused. Programmers are supposed to read system .h files.
Programmers are supposed to know the syntactical and semantical definitions
of a language and the standards involved. That's what makes a portable
program. Not the implementation specific headers.
--
Marcel Moolenaar mailto:marcel@scc.nl
SCC Internetworking & Databases http://www.scc.nl/
The FreeBSD project mailto:marcel@FreeBSD.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37D8288D.B7BC05E2>