From owner-cvs-all@FreeBSD.ORG Fri Mar 18 19:17:06 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F0FE16A4CE; Fri, 18 Mar 2005 19:17:06 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE2AA43D2D; Fri, 18 Mar 2005 19:17:05 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j2IJGXCT039958; Fri, 18 Mar 2005 12:16:34 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <423B288E.3090901@samsco.org> Date: Fri, 18 Mar 2005 12:14:22 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Jeremy References: <20050317.233645.74714466.imp@bsdimp.com> <20050318064521.GA42508@VARK.MIT.EDU> <423A86D9.5030504@portaone.com> <20050318.005008.71126625.imp@bsdimp.com> <423A8B51.3010609@portaone.com> <423A8DC5.5010006@samsco.org> <20050318190828.GC30813@cirb503493.alcatel.com.au> <423B2778.2070206@samsco.org> In-Reply-To: <423B2778.2070206@samsco.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: Maxim Sobolev cc: src-committers@FreeBSD.org cc: cvs-src@FreeBSD.org cc: danfe@FreeBSD.org cc: cvs-all@FreeBSD.org cc: das@FreeBSD.org cc: Warner Losh Subject: Re: cvs commit: src/lib/msun/i387 fenv.c fenv.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2005 19:17:06 -0000 Scott Long wrote: > Peter Jeremy wrote: > >> On Fri, 2005-Mar-18 01:13:57 -0700, Scott Long wrote: >> >>> No, I think that what he's worried about is that you have port foo that >>> generates a library called libfoo.so.1, and that library is linked >>> against libm.so.2. You then have port bar that generates a binary >>> linked against libfoo.so.1 and libm.so.2. Now lets say that libm.so.2 >>> gets bumped to libm.so.3, and you also rebuild port bar. Now bar is >>> linked to libfoo.so.1 and libm.so.3, but libfoo.so.1 is still linked >>> against libm.so.2; >> >> >> >> Is it worthwhile checking (and warning) about this condition? Possible >> options include: >> 1) ld-elf.so learning that a .so is make up of a name and a version >> number >> and whinging if an executable attempts to load two shared libraries >> with >> the same name and different versions. > > > This would definitely be good to have for diagnostic purposes, whether > the mythical library versioning happens or not. ^^^^^^^ symbol > >> 2) ld(1) whinging (and failing) if the shared libraries on the command >> line would result in the final executable being linked against two >> different versions of a shared library. > > > As you point out below, this does nothing for dlopen(), and I don't > think that it'll provide enough useful information for end users. > >> 3) portupgrade (or even port dependency checking) doing an 'ldd' on each >> dependency and either complaining or rebuilding any where the >> dependency >> predates a library bump. (Doing this properly probably means building >> the port then discovering that it now needs multiple .so versions and >> having to rebuild it after cleaning up the offending dependency). > > > Yes, this would be interesting to have also. > > Scott