From owner-freebsd-ports Tue Apr 14 10:56:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA28275 for freebsd-ports-outgoing; Tue, 14 Apr 1998 10:56:49 -0700 (PDT) (envelope-from owner-freebsd-ports@FreeBSD.ORG) Received: from phoenix.volant.org (phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA28269 for ; Tue, 14 Apr 1998 17:56:47 GMT (envelope-from patl@phoenix.volant.org) From: patl@phoenix.volant.org Received: from asimov.phoenix.volant.org [205.179.79.65] by phoenix.volant.org with smtp (Exim 1.62 #1) id 0yP9ws-0000Zp-00; Tue, 14 Apr 1998 10:56:46 -0700 Received: from localhost by asimov.phoenix.volant.org (SMI-8.6/SMI-SVR4) id KAA07440; Tue, 14 Apr 1998 10:54:52 -0700 Date: Tue, 14 Apr 1998 10:54:52 -0700 (PDT) Reply-To: patl@phoenix.volant.org Subject: Re: Libraries To: alk@pobox.com cc: freebsd-ports@FreeBSD.ORG In-Reply-To: <199804141649.LAA12862@pobox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Quoth Chuck Robey on Tue, 14 April: > : 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. > > I had thought the whole point of the .so.maj.min scheme was that > existing applications could continue to use .so.(N-1).x while newly > compiled applications use .so.N.x. They can. In fact, they will. That's the problem. If the newly compiled application relies on something that was in .so.(N-1).x, but isn't in the current .so.N.x, the link against .so will fail. That's why we need to make the dependancy on libMumbleN-1 instead of on libMumble; and why the patches in the port need to munge the Makefiles to explicitly request a specific major and minor number in the links. Yes, it sucks. Blame the library authors that don't maintain backwards source-level compatability. Especially those that don't even bump the major number for an incompatable release. -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message