This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: RFC: Add zlib source to src CVS resposity
- From: Nick Clifton <nickc at redhat dot com>
- To: Binutils <binutils at sourceware dot org>
- Cc: GCC Development <gcc at gcc dot gnu dot org>, GDB <gdb at sourceware dot org>
- Date: Mon, 01 Nov 2010 17:13:44 +0000
- Subject: Re: RFC: Add zlib source to src CVS resposity
- References: <AANLkTikYSxV51_452Wuqox6mQ3_QwNjzNkBgV=NzKk4f__16997.3676828251$1288473196$gmane$org@mail.gmail.com> <y0mhbg3icpj.fsf@fche.csb> <mcr1v762oh6.fsf@google.com> <AANLkTinR-RO0RpKPsSi9E5uUytGaxH-g1bwjRVLMx_V2@mail.gmail.com> <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