From owner-cvs-src@FreeBSD.ORG Fri Mar 18 19:08:44 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8846916A4CE; Fri, 18 Mar 2005 19:08:44 +0000 (GMT) Received: from mail20.syd.optusnet.com.au (mail20.syd.optusnet.com.au [211.29.132.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9839443D54; Fri, 18 Mar 2005 19:08:43 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j2IJ8VRf020086 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 19 Mar 2005 06:08:36 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j2IJ8U7l035118; Sat, 19 Mar 2005 06:08:30 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j2IJ8Uic035117; Sat, 19 Mar 2005 06:08:30 +1100 (EST) (envelope-from pjeremy) Date: Sat, 19 Mar 2005 06:08:29 +1100 From: Peter Jeremy To: Scott Long Message-ID: <20050318190828.GC30813@cirb503493.alcatel.com.au> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423A8DC5.5010006@samsco.org> User-Agent: Mutt/1.4.2i 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-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2005 19:08:44 -0000 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. 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. 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). Note that 2 and 3 don't pick up .so's that are dlopen()d by the code and 3 only works for ports. This is off the top of my head and further thought may suggest reasons why the above aren't practical. -- Peter Jeremy