> 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.
(FWIW, even bugfixes that in theory don't require even minor version
bumps, are known to cause compatibility problems. For example: vfork()
is documented (and always was documented) to share address space. In
practice, i didn't share the address space for a very long time. When
FreeBSD implemented "real" vfork(), some programs broke - they actually
assumed non-shared address space. The sources were fixed, but old
binaries, of course, left broken. NetBSD instead added "real vfork" as
syscall with new number, so old binaries continued to use old vfork
that doesn't share address space.
It is amusing that a less popular OS (NetBSD) cares about compatibility
more than a more popular OS (FreeBSD). I guess, we can learn from them
here. (Well, I have never seen running NetBSD, perhaps if I will see it
I will be disappointed))
>
> The switch from libc5 to glibc2 was more clear. Binaries simply don't work
> if you don't have the right libraries. How painful that can be, it's still
> preferable over a segfault, because you solve that problem by installing
> the libraries and not by patching things up (if at all possible) all over
> system.
>
> > > > 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.
> > 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. 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. 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?)
> > 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).
(2) Other changes, in particular the sigset_t changes, can/should be done
by just adding new functions.
All your previous arguments are arguments against (1), right? I still hope
to start discuss (2)...
> > 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. Also, have a
look at <arpa/inet.h> some day. Don't rename 'foo' to 'bar'. Rename
'foo' to, say, '__foo40', so programmers will get idea that something
wrong with 'foo'. Seriously, I am a programmer and I will not be
confused. Programmers are supposed to read system .h files.
Dima
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
