[patch] update zlib to the 1.2.10 release.

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[patch] update zlib to the 1.2.10 release.

Matthias Klose-6
These are the changes updating zlib from 1.2.8 to 1.2.10. It is only used when
building without a system zlib.  The new release includes fixes for security
issues CVE-2016-9840, CVE-2016-9841, CVE-2016-9842, CVE-2016-9843.

Checked with a build with disabled system-zlib. Ok for the trunk?

Matthias


Changes in 1.2.10 (2 Jan 2017)
- Avoid warnings on snprintf() return value
- Fix bug in deflate_stored() for zero-length input
- Fix bug in gzwrite.c that produced corrupt gzip files
- Remove files to be installed before copying them in Makefile.in
- Add warnings when compiling with assembler code

Changes in 1.2.9 (31 Dec 2016)
- Fix contrib/minizip to permit unzipping with desktop API [Zouzou]
- Improve contrib/blast to return unused bytes
- Assure that gzoffset() is correct when appending
- Improve compress() and uncompress() to support large lengths
- Fix bug in test/example.c where error code not saved
- Remedy Coverity warning [Randers-Pehrson]
- Improve speed of gzprintf() in transparent mode
- Fix inflateInit2() bug when windowBits is 16 or 32
- Change DEBUG macro to ZLIB_DEBUG
- Avoid uninitialized access by gzclose_w()
- Allow building zlib outside of the source directory
- Fix bug that accepted invalid zlib header when windowBits is zero
- Fix gzseek() problem on MinGW due to buggy _lseeki64 there
- Loop on write() calls in gzwrite.c in case of non-blocking I/O
- Add --warn (-w) option to ./configure for more compiler warnings
- Reject a window size of 256 bytes if not using the zlib wrapper
- Fix bug when level 0 used with Z_HUFFMAN or Z_RLE
- Add --debug (-d) option to ./configure to define ZLIB_DEBUG
- Fix bugs in creating a very large gzip header
- Add uncompress2() function, which returns the input size used
- Assure that deflateParams() will not switch functions mid-block
- Dramatically speed up deflation for level 0 (storing)
- Add gzfread(), duplicating the interface of fread()
- Add gzfwrite(), duplicating the interface of fwrite()
- Add deflateGetDictionary() function
- Use snprintf() for later versions of Microsoft C
- Fix *Init macros to use z_ prefix when requested
- Replace as400 with os400 for OS/400 support [Monnerat]
- Add crc32_z() and adler32_z() functions with size_t lengths
- Update Visual Studio project files [AraHaan]

zlib-1.2.10.diff.gz (127K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [patch] update zlib to the 1.2.10 release.

Jeff Law
On 01/05/2017 07:45 AM, Matthias Klose wrote:
> These are the changes updating zlib from 1.2.8 to 1.2.10. It is only used when
> building without a system zlib.  The new release includes fixes for security
> issues CVE-2016-9840, CVE-2016-9841, CVE-2016-9842, CVE-2016-9843.
>
> Checked with a build with disabled system-zlib. Ok for the trunk?
Were there any changes that we needed to carry forward or any changes
you needed to make to the upstream sources?

Jeff

Reply | Threaded
Open this post in threaded view
|

Re: [patch] update zlib to the 1.2.10 release.

Matthias Klose-6
On 12.01.2017 22:17, Jeff Law wrote:
> On 01/05/2017 07:45 AM, Matthias Klose wrote:
>> These are the changes updating zlib from 1.2.8 to 1.2.10. It is only used when
>> building without a system zlib.  The new release includes fixes for security
>> issues CVE-2016-9840, CVE-2016-9841, CVE-2016-9842, CVE-2016-9843.
>>
>> Checked with a build with disabled system-zlib. Ok for the trunk?
> Were there any changes that we needed to carry forward or any changes you needed
> to make to the upstream sources?

I backed out the changes to the configure* and Makefile* changes (and only
these), which are completely different to zlib upstream. There are no
additions/deletions to zlib source files, so these build changes still work with
the updated zlib.

Matthias

Reply | Threaded
Open this post in threaded view
|

Re: [patch] update zlib to the 1.2.10 release.

Jeff Law
On 01/12/2017 02:26 PM, Matthias Klose wrote:

> On 12.01.2017 22:17, Jeff Law wrote:
>> On 01/05/2017 07:45 AM, Matthias Klose wrote:
>>> These are the changes updating zlib from 1.2.8 to 1.2.10. It is only used when
>>> building without a system zlib.  The new release includes fixes for security
>>> issues CVE-2016-9840, CVE-2016-9841, CVE-2016-9842, CVE-2016-9843.
>>>
>>> Checked with a build with disabled system-zlib. Ok for the trunk?
>> Were there any changes that we needed to carry forward or any changes you needed
>> to make to the upstream sources?
>
> I backed out the changes to the configure* and Makefile* changes (and only
> these), which are completely different to zlib upstream. There are no
> additions/deletions to zlib source files, so these build changes still work with
> the updated zlib.
OK.  I'm a little concerned that we may be losing local changes --
though it looks like you've done this process a couple times already, so
I'll assume you're aware of potential pitfalls.

Go ahead and install on the trunk.  If it causes problems we can't
address quickly and safely we may have to rethink.

jeff
Reply | Threaded
Open this post in threaded view
|

Re: [patch] update zlib to the 1.2.10 release.

Jeff Law
In reply to this post by Matthias Klose-6
On 01/12/2017 02:26 PM, Matthias Klose wrote:

> On 12.01.2017 22:17, Jeff Law wrote:
>> On 01/05/2017 07:45 AM, Matthias Klose wrote:
>>> These are the changes updating zlib from 1.2.8 to 1.2.10. It is only used when
>>> building without a system zlib.  The new release includes fixes for security
>>> issues CVE-2016-9840, CVE-2016-9841, CVE-2016-9842, CVE-2016-9843.
>>>
>>> Checked with a build with disabled system-zlib. Ok for the trunk?
>> Were there any changes that we needed to carry forward or any changes you needed
>> to make to the upstream sources?
>
> I backed out the changes to the configure* and Makefile* changes (and only
> these), which are completely different to zlib upstream. There are no
> additions/deletions to zlib source files, so these build changes still work with
> the updated zlib.
One more note.  I think that, in general, backing out local changes
which don't have a strong need to be carried forward is absolutely the
right thing to do.  The less hacking we do on these libraries we pull
from other sources, the better, IMHO.

jeff
Reply | Threaded
Open this post in threaded view
|

Re: [patch] update zlib to the 1.2.10 release.

Matthias Klose-6
On 12.01.2017 22:39, Jeff Law wrote:

> On 01/12/2017 02:26 PM, Matthias Klose wrote:
>> On 12.01.2017 22:17, Jeff Law wrote:
>>> On 01/05/2017 07:45 AM, Matthias Klose wrote:
>>>> These are the changes updating zlib from 1.2.8 to 1.2.10. It is only used when
>>>> building without a system zlib.  The new release includes fixes for security
>>>> issues CVE-2016-9840, CVE-2016-9841, CVE-2016-9842, CVE-2016-9843.
>>>>
>>>> Checked with a build with disabled system-zlib. Ok for the trunk?
>>> Were there any changes that we needed to carry forward or any changes you needed
>>> to make to the upstream sources?
>>
>> I backed out the changes to the configure* and Makefile* changes (and only
>> these), which are completely different to zlib upstream. There are no
>> additions/deletions to zlib source files, so these build changes still work with
>> the updated zlib.
> One more note.  I think that, in general, backing out local changes which don't
> have a strong need to be carried forward is absolutely the right thing to do.
> The less hacking we do on these libraries we pull from other sources, the
> better, IMHO.

agreed, except for the build system (and a locally fixed typo in zlib's
ChangeLog), everything applied cleanly.

Please import it into the binutils-gdb repository.

Matthias

Reply | Threaded
Open this post in threaded view
|

Re: [patch] update zlib to the 1.2.10 release.

Matthias Klose-6
In reply to this post by Jeff Law
On 12.01.2017 22:39, Jeff Law wrote:

> On 01/12/2017 02:26 PM, Matthias Klose wrote:
>> On 12.01.2017 22:17, Jeff Law wrote:
>>> On 01/05/2017 07:45 AM, Matthias Klose wrote:
>>>> These are the changes updating zlib from 1.2.8 to 1.2.10. It is only used when
>>>> building without a system zlib.  The new release includes fixes for security
>>>> issues CVE-2016-9840, CVE-2016-9841, CVE-2016-9842, CVE-2016-9843.
>>>>
>>>> Checked with a build with disabled system-zlib. Ok for the trunk?
>>> Were there any changes that we needed to carry forward or any changes you needed
>>> to make to the upstream sources?
>>
>> I backed out the changes to the configure* and Makefile* changes (and only
>> these), which are completely different to zlib upstream. There are no
>> additions/deletions to zlib source files, so these build changes still work with
>> the updated zlib.
> One more note.  I think that, in general, backing out local changes which don't
> have a strong need to be carried forward is absolutely the right thing to do.
> The less hacking we do on these libraries we pull from other sources, the
> better, IMHO.
Committed the 1.2.10 changes on Jan 13.  1.2.11 was released a few days ago.
Updating the trunk with the new version, checked with a build without using a
system zlib.

NightStrike proposed to revert to the 1.2.8 release until zlib stabilizes again;
I'm open for that, but didn't want to stay with the 1.2.10 release.

Matthias

2017-01-22  Matthias Klose  <[hidden email]>

        * Import zlib 1.2.11.
        * configure: Regenerate.

Changes in 1.2.11 (15 Jan 2017)
- Fix deflate stored bug when pulling last block from window
- Permit immediate deflateParams changes before any deflate input



zlib-1.2.11.diff (39K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [patch] update zlib to the 1.2.10 release.

NightStrike
On Sun, Jan 22, 2017 at 1:00 PM, Matthias Klose <[hidden email]> wrote:
> NightStrike proposed to revert to the 1.2.8 release until zlib stabilizes again;
> I'm open for that, but didn't want to stay with the 1.2.10 release.

I don't recall making that proposal.  I thought I just suggested that
since modern zlib now supports having a separate build and source
directory (at least according to the December changelog: "Allow
building zlib outside of the source directory"), you should check to
see if the gcc build system had any hacks to accomplish the same thing
that could now be removed.
Reply | Threaded
Open this post in threaded view
|

Re: [patch] update zlib to the 1.2.10 release.

Matthias Klose-6
On 22.01.2017 19:12, NightStrike wrote:

> On Sun, Jan 22, 2017 at 1:00 PM, Matthias Klose <[hidden email]> wrote:
>> NightStrike proposed to revert to the 1.2.8 release until zlib stabilizes again;
>> I'm open for that, but didn't want to stay with the 1.2.10 release.
>
> I don't recall making that proposal.  I thought I just suggested that
> since modern zlib now supports having a separate build and source
> directory (at least according to the December changelog: "Allow
> building zlib outside of the source directory"), you should check to
> see if the gcc build system had any hacks to accomplish the same thing
> that could now be removed.

sorry for wrongly citing you.  Please could you make the removal of zlib a goal
for GCC 8?  I may be a bit biased trying to keep the "ongoing" d/gdc merge alive
(libgphobos requiring a target zlib).

Matthias

Reply | Threaded
Open this post in threaded view
|

Re: [patch] update zlib to the 1.2.10 release.

Joel Brobecker
In reply to this post by Matthias Klose-6
> On 12.01.2017 22:17, Jeff Law wrote:
> > On 01/05/2017 07:45 AM, Matthias Klose wrote:
> >> These are the changes updating zlib from 1.2.8 to 1.2.10. It is only used when
> >> building without a system zlib.  The new release includes fixes for security
> >> issues CVE-2016-9840, CVE-2016-9841, CVE-2016-9842, CVE-2016-9843.
> >>
> >> Checked with a build with disabled system-zlib. Ok for the trunk?
> > Were there any changes that we needed to carry forward or any changes you needed
> > to make to the upstream sources?
>
> I backed out the changes to the configure* and Makefile* changes (and
> only these), which are completely different to zlib upstream. There
> are no additions/deletions to zlib source files, so these build
> changes still work with the updated zlib.

Can you tell us what these changes are? Currently nightly source
packaging is broken while configuring zlib.

Here is what I am seeing:

    $ cd /path/to/gdb/sources
    $ ./configure --target=i386-pc-linux-gnu
    $ make configure-host configure-target
    [...]
    checking for strerror... yes
    checking for unistd.h... (cached) yes
    configure: updating cache ./config.cache
    configure: creating ./config.status
    config.status: creating Makefile
    config.status: executing default-1 commands
    ./config.status: line 1191: ./../../config-ml.in: No such file or directory
    Makefile:10001: recipe for target 'configure-zlib' failed
    make: *** [configure-zlib] Error 1

Thanks,
--
Joel
Reply | Threaded
Open this post in threaded view
|

Re: [patch] update zlib to the 1.2.10 release.

Matthias Klose-6
On 23.01.2017 05:09, Joel Brobecker wrote:

>> On 12.01.2017 22:17, Jeff Law wrote:
>>> On 01/05/2017 07:45 AM, Matthias Klose wrote:
>>>> These are the changes updating zlib from 1.2.8 to 1.2.10. It is only used when
>>>> building without a system zlib.  The new release includes fixes for security
>>>> issues CVE-2016-9840, CVE-2016-9841, CVE-2016-9842, CVE-2016-9843.
>>>>
>>>> Checked with a build with disabled system-zlib. Ok for the trunk?
>>> Were there any changes that we needed to carry forward or any changes you needed
>>> to make to the upstream sources?
>>
>> I backed out the changes to the configure* and Makefile* changes (and
>> only these), which are completely different to zlib upstream. There
>> are no additions/deletions to zlib source files, so these build
>> changes still work with the updated zlib.
>
> Can you tell us what these changes are? Currently nightly source
> packaging is broken while configuring zlib.
>
> Here is what I am seeing:
>
>     $ cd /path/to/gdb/sources
>     $ ./configure --target=i386-pc-linux-gnu
>     $ make configure-host configure-target
>     [...]
>     checking for strerror... yes
>     checking for unistd.h... (cached) yes
>     configure: updating cache ./config.cache
>     configure: creating ./config.status
>     config.status: creating Makefile
>     config.status: executing default-1 commands
>     ./config.status: line 1191: ./../../config-ml.in: No such file or directory
>     Makefile:10001: recipe for target 'configure-zlib' failed
>     make: *** [configure-zlib] Error 1

I didn't change the configure and Makefile files at all. I see that Nick synced
the configure.ac from the GCC tree, and that introduced one extra change:

--- a/zlib/configure.ac
+++ b/zlib/configure.ac
@@ -4,9 +4,7 @@ AC_PREREQ(2.64)
 AC_INIT
 AC_CONFIG_SRCDIR([zlib.h])

-if test -n "${with_target_subdir}"; then
-  AM_ENABLE_MULTILIB(, ..)
-fi
+AM_ENABLE_MULTILIB(, ..)

 AC_CANONICAL_SYSTEM


Builds with srcdir != builddir still work.

Matthias

Reply | Threaded
Open this post in threaded view
|

Re: [patch] update zlib to the 1.2.10 release.

Nick Clifton
In reply to this post by Joel Brobecker
Hi Joel,

> Can you tell us what these changes are? Currently nightly source
> packaging is broken while configuring zlib.

>     ./config.status: line 1191: ./../../config-ml.in: No such file or directory
>     Makefile:10001: recipe for target 'configure-zlib' failed

I have checked in a patch to restore the old behaviour to zlib's Makefile
and allow building with srcdir == builddir.  At least for now.  If we do
decide to ban this behaviour then this patch can be reverted, or a top level
check and warning added.

Cheers
  Nick

zlib/ChangeLog.bin-gdb
2017-01-23  Nick Clifton  <[hidden email]>

        * configure.ac: Restore old behaviour of only enabling multilibs
        when a target subdirectory is defined.  This allows building with
        srcdir == builddir.
        * configure: Regenerate.

Reply | Threaded
Open this post in threaded view
|

Re: [patch] update zlib to the 1.2.10 release.

Iain Buclaw
In reply to this post by Matthias Klose-6
On 22 January 2017 at 19:42, Matthias Klose <[hidden email]> wrote:

> On 22.01.2017 19:12, NightStrike wrote:
>> On Sun, Jan 22, 2017 at 1:00 PM, Matthias Klose <[hidden email]> wrote:
>>> NightStrike proposed to revert to the 1.2.8 release until zlib stabilizes again;
>>> I'm open for that, but didn't want to stay with the 1.2.10 release.
>>
>> I don't recall making that proposal.  I thought I just suggested that
>> since modern zlib now supports having a separate build and source
>> directory (at least according to the December changelog: "Allow
>> building zlib outside of the source directory"), you should check to
>> see if the gcc build system had any hacks to accomplish the same thing
>> that could now be removed.
>
> sorry for wrongly citing you.  Please could you make the removal of zlib a goal
> for GCC 8?  I may be a bit biased trying to keep the "ongoing" d/gdc merge alive
> (libgphobos requiring a target zlib).
>
> Matthias
>

I'd certainly have no problem having zlib as external-only.  The
phobos library also has a dependency on curl in much the same way, but
we don't bundle such in as a convenience library.

But I'm sure I'm not the only user of zlib, doesn't the LTO frontend
support compression?

Iain.