From owner-freebsd-hackers Thu Sep 9 9:21:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gaia.euronet.nl (gaia.euronet.nl [194.134.0.10]) by hub.freebsd.org (Postfix) with ESMTP id 44E2B15CEA for ; Thu, 9 Sep 1999 09:21:25 -0700 (PDT) (envelope-from marcel@scc.nl) Received: from scones.sup.scc.nl (i333.ztm.euronet.nl [194.134.67.94]) by gaia.euronet.nl (8.8.8/8.8.8) with ESMTP id SAA04150; Thu, 9 Sep 1999 18:20:59 +0200 (MET DST) Received: from scc.nl (scones.sup.scc.nl [192.168.2.4]) by scones.sup.scc.nl (8.9.3/8.9.3) with ESMTP id SAA05198; Thu, 9 Sep 1999 18:20:56 +0200 (CEST) (envelope-from marcel@scc.nl) Message-ID: <37D7DE68.5441D879@scc.nl> Date: Thu, 09 Sep 1999 18:20:56 +0200 From: Marcel Moolenaar Organization: SCC vof X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5 i386) X-Accept-Language: en MIME-Version: 1.0 To: Dmitrij Tejblum Cc: hackers@FreeBSD.ORG Subject: Re: 32+ signals and library versions References: <199909091436.SAA04752@arc.hq.cti.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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