This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Add zlib source to src CVS resposity

"H.J. Lu" <> writes:

> On Sun, Oct 31, 2010 at 11:42 AM, Ian Lance Taylor <> wrote:
>> (Frank Ch. Eigler) writes:
>>> "H.J. Lu" <> writes:
>>>> [...] ÂBy default, the in-tree zlib is used. ÂIf you configure
>>>> binutis using --with-system-zlib, system zlib will be used. Â[...]
>>> Can you summarize what modern platforms lack a system zlib, and what
>>> justifies using the proposed in-tree copy by default?
>> This is a good point. ÂWe need zlib in the gcc repository because we
>> build it for the target, but this issue does not arise in the src
>> repository. Â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?
> zlib is in similar situation as intl. We include intl in binutils src and
> it can be disabled at configure time. For host zlib, should we check if
> it is available and fail back to in-tree zlib if there is no suitable host
> zlib?

I assume that the reason we do that for intl is because it has complex
interactions with the rest of the C library, so using the wrong intl
library will cause confusing behaviour when the LC_ environment
variables are set.  That case does not arise for zlib.  I think that if
we do ship zlib with the binutils, we might as well always build it
rather than using complex configure tests.

This is just my opinion, and really I think the more active binutils and
gdb maintainers should decide what to do here.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]