Marcel Moolenaar wrote:
> 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.
This is just a call for the linux way: libc.so.6 -> libc-2.1.1.so. I
don't actually like it (for mostly aestetical reasons), but certainly can live
with it.
> From your words: if you don't change an existing library, but provide an
> alternative, then compatibility isn't in danger.
Perhaps (see the end of my mail). But the progress is in danger. (FWIW,
progress is the only reason to ever upgrade FreeBSD). The old library is
probably buggy. See PR bin/13623 for a real-life example. (Nate apparently
ignored it :-().
>
> > (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?
See above. (Also, libraries should/can have rcsids linked in).
> > > > > > 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.
Umm, no, rtld is the only player with old binaries. Anyway, I don't
really care about it.
>
> > > > 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.
??? What recompile? Why do you think I have the sources - there is
quite a few binary-only FreeBSD programs? Why should I waste my time by
recompiling and reinstalling something? Why should I waste my time and
network bandwidth by downloading every package twice - for -stable and
for -current?
>
> > 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.
No! This is the whole point. Of course, NetBSD renamed "new" vfork to
something like __vfork14, so new binaries actually call __vfork14(),
while old binaries call vfork(). Everything happy.
> > 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,
I can't parse the above line
> 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.
You described the existing situation. You could notice that I suggest to
change it. I suggest that libc should actively maintain compatibility. I
suggest to add code for it. I suggest that library versioning should not be
used.
> > >
> > > 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 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.
My point is just that NetBSD give an experience, in particular w.r.t. POLA
violations. You also ignored my refence to <arpa/inet.h>. I will
expand: When you see call to inet_aton() in the source, your object file
actually call __inet_aton(). This is quite similar to the thing I
suggest. This is the case at least still 3.0-RELEASE. From this
experience we can say that POLA violation here is very low.
> > > 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.
> >
> > 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.
Yeah, but only until they see an error message. A lot of error messages are
really hard to understand without looking at the implementation specific
headers. (Then again, not every program is supposed to be portable.)
---
OK, I failed to convince you. New attempt: I am switching to your
original question.
> Since libc and libc_r have changed on the interface level, they
> need a version bump. I assume that all others automaticly also need a
> version bump then. Am I correct in this assumption?
Yes. You need to manually bump version of every other library,
including those from ports. You also going to have some fun when the
version of the "other library" need to be bumped by its internal
vendor-specific reasons.
Look: suppose there is libfoo.so.15, that use, say, setjmp() for its
internal purposes. If you didn't recompile the library, you cannot
build new programs with it: the library will call setjmp() from
libc.so.4, while it want to call setjmp() from libc.so.3. (NOTE! The
users WILL experience the "Linux syndrome" here if they don't recompile
everything together with the libc upgrade.) If you recompile libfoo and
didn't bump its version, old programs linked with libc.so.3 will break -
libfoo will call setjmp() from libc.so.3 where it want to call setjmp()
from libc.so.4. So, you have to bump the version number.
You probably already understand above. So, what's the plan? Do you
actually plan to bump the version of every library under the moon? Or
you will say - oh, if some programs borke, just recompile them? Or do
something like linux when they switched from libc5 to libc6 - I believe
they have had separate directories for libc5 and libc6 worlds?
With my scheme, if the rtld see a call to setjmp, it know it is the old
setjmp, if it see a call to __setjmp40, it know it is the new setjmp.
Isn't it clear and unambiquous? You can have old binary that call old
setjmp linked with shared library that call new __setjmp40. Of course,
if the library interface have something sigset-related, you are still
in trouble, but it is unlikely and you would have to deal with the
trouble anyway.
Dima
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
