From owner-freebsd-mozilla Tue Apr 14 09:09:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA09069 for freebsd-mozilla-outgoing; Tue, 14 Apr 1998 09:09:07 -0700 (PDT) (envelope-from owner-freebsd-mozilla@FreeBSD.ORG) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA08979; Tue, 14 Apr 1998 16:08:55 GMT (envelope-from chuckr@glue.umd.edu) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.8.8/8.8.5) with SMTP id LAA00831; Tue, 14 Apr 1998 11:07:47 -0400 (EDT) Date: Tue, 14 Apr 1998 11:07:47 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@localhost To: gnat@frii.com cc: Satoshi Asami , freebsd-ports@FreeBSD.ORG, freebsd-mozilla@FreeBSD.ORG Subject: Re: Libraries In-Reply-To: <199804141450.IAA26379@prometheus.frii.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-mozilla@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 14 Apr 1998 gnat@frii.com wrote: > Satoshi Asami writes: > > The library names with version numbers are those that have proven in > > the past to upgrade without preserving backwards compatibility. > > I figured that's what it was. > > > Usually that is solved by bumping the major shlib number, but we can't > > do that for libraries that are used by dozens of other ports. Because > > the way FreeBSD shared libraries work, it is not possible to smoothly > > transition from one version to another without changing the "base" > > name (as you see in libtiff or libtcl). > > Urk. What algorithm, then, should autoconf use to (a) find the > j. random name of the library, (b) that library's include files, and > (c) whether the library+include files are compatible with how it > works? (c) is obviously "compile and run a test program" but what > about (a) and (b)? > > It seems to me that FreeBSD's shared library system must be > ill-designed if (a) and (b) are as difficult as it seems. It's not ill designed, it's ill-designed upgrades of software that's to blame. Classic case in point is the tcl stuff. If the newer versions were compatible with older versions, we wouldn't have or need abortions like libtcl81, we'd just have libtcl, and the linker would simply pick up the latest version. The trouble comes in when there are library upgrades which orphan existing applications, so you must be able to to have both lib versions on hand to run a given set of applications. You don't want our linker then to pick the latest version, so the basename has to be modified. > > Thanks, > > Nat > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ports" in the body of the message > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mozilla" in the body of the message