From owner-freebsd-current Wed May 20 16:27:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA23108 for freebsd-current-outgoing; Wed, 20 May 1998 16:27:55 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp04.primenet.com (daemon@smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA23086 for ; Wed, 20 May 1998 16:27:40 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id QAA14581; Wed, 20 May 1998 16:27:33 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp04.primenet.com, id smtpd014521; Wed May 20 16:27:24 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id QAA02369; Wed, 20 May 1998 16:27:20 -0700 (MST) From: Terry Lambert Message-Id: <199805202327.QAA02369@usr04.primenet.com> Subject: Re: Fix for undefined "__error" and discussion of shared object versioning To: syssgm@dtir.qld.gov.au (Stephen McKay) Date: Wed, 20 May 1998 23:27:20 +0000 (GMT) Cc: tlambert@primenet.com, freebsd-current@FreeBSD.ORG, syssgm@dtir.qld.gov.au In-Reply-To: <199805200747.RAA09525@troll.dtir.qld.gov.au> from "Stephen McKay" at May 20, 98 05:47:10 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >The difference in the output is because PHK's malloc always fails a > >``readlink("/etc/malloc.conf");'' and sets errno = ENOENT (2). > > This explains the errno of 2. fake_used should be 0. I explain the > count of 2 by assuming that one is for the assignment to errno, and > the other for the read of errno. Our ___error() should not have been > called at all in this example. So, it's not working properly after all. > > I am keen to make this work, but don't know how. Why don't weak symbols > work for this? Use the real symbol names. I don't know why what you are doing won't work, but it's *not* what I'm doing, wo it really doesn't matter why it doesn't work because it's the wrong thing to do anyway. > >> I don't see how your major/minor/subminor is any better than the > >> current major/minor, or how it would avoid the current problem. > > > >It would avoid the problem by letting us bump the minor but not the > >subminor when the errno.h change went in. So long as you did not > >foolishly replace an existing library of the same major/minor that > >you had built on your own, the executable would continue to prefer > >the old library to the new library you had built. > > What you are saying is that we would bump the minor numbers on all > libraries with your system, as opposed to bumping the major numbers > on all libraries with the current system. This gains nothing as far > as I can see. It gains you the ability to keep running the binaries that you won't (or can't) relink against the correct libc, when you are willing to rebuild the other libraries (for no reason that I can tell) to make them depend on the new libc. It's a magic hand-wave to let you run programs that weren't linked for -current with libc's from -stable and other shared libraries not-from-stable-but-from-current. The real problem here is that you shouldn't be rebuilding libraries that your old programs would bind to, adding new dependencies in the process. I think the soloution is to make the old programs continue to bind to old libraries. But to be able to add bug fixes to them at the same time (thus allowing you to wantonly rebuild them), you need a subminor version, and a binding preference for a given minor. When the 3.0-release happens, then the major numbers can be bumped, and the minors and subminors will be rezero-ed. So it doesn't matter how large the minor number get in the developement branch, so long as it resets on the release. Beasically, it prevents FreeBSD from looking like the consequences of library changes weren't thought out (which they weren't) by adding a mechanism to prevent high-speed major version increments (incidently, by thinking it out). It divorces the idea of additions from the idea of dependent additions (and/or subtractions). If I add the function "foo" to a library, you could care less. If I added the function "__error", and then made all new code call it, then you start to care. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message