public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Clifton <nickc@redhat.com>
To: Binutils <binutils@sourceware.org>
Cc: GCC Development <gcc@gcc.gnu.org>, GDB <gdb@sourceware.org>
Subject: Re: RFC: Add zlib source to src CVS resposity
Date: Mon, 01 Nov 2010 17:13:00 -0000	[thread overview]
Message-ID: <4CCEF548.4000502@redhat.com> (raw)
In-Reply-To: <mcrk4ky18i6.fsf@google.com>

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

  reply	other threads:[~2010-11-01 17:13 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AANLkTikYSxV51_452Wuqox6mQ3_QwNjzNkBgV=NzKk4f__16997.3676828251$1288473196$gmane$org@mail.gmail.com>
2010-10-30 21:37 ` Frank Ch. Eigler
2010-10-30 22:28   ` H.J. Lu
2010-10-31 18:42   ` Ian Lance Taylor
2010-10-31 18:58     ` H.J. Lu
2010-10-31 19:13       ` Ian Lance Taylor
2010-11-01 17:13         ` Nick Clifton [this message]
2010-11-01 17:19           ` Daniel Jacobowitz
2010-11-01 23:56           ` Alan Modra
2010-11-02  1:03             ` Christopher Faylor
2010-11-02  8:19               ` Nick Clifton
2010-11-02 13:22                 ` Ian Lance Taylor
2010-11-09 14:19                   ` Mike Frysinger
2010-11-02 10:46         ` Paolo Bonzini
2010-10-31 19:54     ` Weddington, Eric
2010-10-30 21:12 H.J. Lu
2010-10-30 22:19 ` John Reiser
2010-11-01 17:21   ` Nick Clifton
2010-11-01 17:23     ` Nathan Froyd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CCEF548.4000502@redhat.com \
    --to=nickc@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=gcc@gcc.gnu.org \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).