Date: Thu, 09 Sep 1999 18:20:56 +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: <37D7DE68.5441D879@scc.nl> References: <199909091436.SAA04752@arc.hq.cti.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
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.
> 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).
> 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.
> 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.
--
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?37D7DE68.5441D879>