From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14019 invoked by alias); 1 Nov 2010 17:13:57 -0000 Received: (qmail 13901 invoked by uid 22791); 1 Nov 2010 17:13:56 -0000 X-SWARE-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 01 Nov 2010 17:13:54 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oA1HDjW0030865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Nov 2010 13:13:46 -0400 Received: from [10.36.4.17] (vpn1-4-17.ams2.redhat.com [10.36.4.17]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id oA1HDi59004732; Mon, 1 Nov 2010 13:13:45 -0400 Message-ID: <4CCEF548.4000502@redhat.com> Date: Mon, 01 Nov 2010 17:13:00 -0000 From: Nick Clifton User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7 MIME-Version: 1.0 To: Binutils CC: GCC Development , GDB Subject: Re: RFC: Add zlib source to src CVS resposity References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2010-11/txt/msg00011.txt.bz2 Hi Guys, >>> So this becomes a question for the binutils maintainers: do >>> the binutils want to be self-contained, or do they want to follow the >>> path of gcc and require additional libraries to be installed before a >>> build can succeed? As I see it the pros of having a copy of the zlib sources in the binutils tree are that: * The tools can be built on a host that does not have zlib installed. * We can be sure exactly which version of zlib is being used. * It simplifies our configure scripts and sources. We always know that zlib is present and the API to use. Whereas the cons of having our own copy of zlib are that: * We have to manually import any bug-fixes or enhancements to the official zlib sources. Which means that we have to watch the zlib sources and be ready to evaluate any changes. * We have to make sure that zlib will build on all of the hosts that we care about. Should the situation arise where the zlib does not build on a particular host, and the zlib maintainers are not interested in making it build there, then it will be down to us to fix it. Or else abandon compression support on that host. * It is essentially a waste of space on hosts that already have zlib installed. At the moment I feel that the pros outweigh the cons. What do other people think ? Cheers Nick