From owner-freebsd-current Tue Mar 28 02:55:39 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA07464 for current-outgoing; Tue, 28 Mar 1995 02:55:39 -0800 Received: from isl.cf.ac.uk (isl-gate.elsy.cf.ac.uk [131.251.22.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA07450 for ; Tue, 28 Mar 1995 02:55:29 -0800 Received: (from paul@localhost) by isl.cf.ac.uk (8.6.9/8.6.9) id LAA18030; Tue, 28 Mar 1995 11:55:04 +0100 From: Paul Richards Message-Id: <199503281055.LAA18030@isl.cf.ac.uk> Subject: Re: shared library versioning To: bde@zeta.org.au (Bruce Evans) Date: Tue, 28 Mar 1995 11:55:03 +0100 (BST) Cc: bde@zeta.org.au, wollman@halloran-eldar.lcs.mit.edu, current@FreeBSD.org In-Reply-To: <199503281038.UAA19653@godzilla.zeta.org.au> from "Bruce Evans" at Mar 28, 95 08:38:35 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1706 Sender: current-owner@FreeBSD.org Precedence: bulk In reply to Bruce Evans who said > >Because when a new function is added to a library, the minor version > >number needs to be incremented, so that users don't get confused. > > I asked why just for this change. New globals in the application's > namespace have been introduced in the following libraries since 2.0R: Because we've just realised it needs doing :-) > > libc: only the strhash globals. > libdialog: many new globals. > libforms: many new globals. Many interface changes. > libg++: some regexp globals removed. > libgcc: many globals removed, but we've already fixed the problems. > libncurses: many new globals. Some removed. Some renamed. > libreadline: many new globals. One removed. > libtermcap: one new global. > We'll have to go and fix all these soon. > The strhash module should be moved to some more volatile library so > that the version number of libc can be left alone. The minor or major > version number of the others should be bumped for 2.1. I'm not so sure adding strhash to libc was such a good idea, it was a bit of a rushed decision on mine and Jordan's part. My main reason, apart from Bruce's points, is that it's not an expected component of libc and we've therefore made anything that uses strhash very non-portable. We should pull strhash out into a separate library which we can take with us to other platforms if we ever need to. There are probably other components of libc that we could do the same for. -- Paul Richards, FreeBSD core team member. Internet: paul@FreeBSD.org, URL: http://isl.cf.ac.uk/~paul/ Phone: +44 1222 874000 x6646 (work), +44 1222 457651 (home) Dept. Mechanical Engineering, University of Wales, College Cardiff.