From owner-cvs-all@FreeBSD.ORG Fri Aug 24 22:25:33 2007 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C0DE16A417; Fri, 24 Aug 2007 22:25:33 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 284D613C45A; Fri, 24 Aug 2007 22:25:28 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.1/8.14.1/NETPLEX) with ESMTP id l7OMPH3h016514; Fri, 24 Aug 2007 18:25:17 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.netplex.net [204.213.176.10]); Fri, 24 Aug 2007 18:25:18 -0400 (EDT) Date: Fri, 24 Aug 2007 18:25:17 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Alfred Perlstein In-Reply-To: <20070824220244.GH87451@elvis.mu.org> Message-ID: References: <200708230509.l7N59VCi048341@repoman.freebsd.org> <20070824183630.GA99474@comp.chem.msu.su> <20070824215515.GF16131@turion.vk2pj.dyndns.org> <20070824220244.GH87451@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org, Yar Tikhiy Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2007 22:25:33 -0000 On Fri, 24 Aug 2007, Alfred Perlstein wrote: > Not to pick on anyone here but Yar did something that works, > why exactly are we not allowing him to use the tools provided > for this exact purpose and instead making him do convoluted > workarounds? > > I mean seriously, so we have a versioned symbol that could > possibly be avoided by a lot of hard work and magic which will > probably fail for a bunch of users.... > > ...so why not just use what works? Please, enough of this "it works, so why not?". We didn't always have symbol versioning, and we have solved these problems before without it. There seems to be an inherent problem with our build system, and the LD_LIBRARY_PATH trick seems to make sense to me, or building and installing the install tools as static to avoid problems like this. I never added symbol versioning to libc in order to solve -current upgrade problems. Sure, you're free to use it that way, but it would not make me very happy ;-) -- DE