Re: [patch] update zlib to the 1.2.10 release.
On 22 January 2017 at 19:42, Matthias Klose wrote: > On 22.01.2017 19:12, NightStrike wrote: >> On Sun, Jan 22, 2017 at 1:00 PM, Matthias Klose 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.
Re: [patch] update zlib to the 1.2.10 release.
On 22.01.2017 19:12, NightStrike wrote: > On Sun, Jan 22, 2017 at 1:00 PM, Matthias Klose 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
Re: [patch] update zlib to the 1.2.10 release.
On Sun, Jan 22, 2017 at 1:00 PM, Matthias Klose 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.
Re: [patch] update zlib to the 1.2.10 release.
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
* 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
Index: zlib/CMakeLists.txt
===
--- zlib/CMakeLists.txt (revision 244761)
+++ zlib/CMakeLists.txt (working copy)
@@ -3,7 +3,7 @@
project(zlib C)
-set(VERSION "1.2.10")
+set(VERSION "1.2.11")
option(ASM686 "Enable building i686 assembly implementation")
option(AMD64 "Enable building amd64 assembly implementation")
Index: zlib/ChangeLog
===
--- zlib/ChangeLog (revision 244761)
+++ zlib/ChangeLog (working copy)
@@ -1,6 +1,10 @@
ChangeLog file for zlib
+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
+
Changes in 1.2.10 (2 Jan 2017)
- Avoid warnings on snprintf() return value
- Fix bug in deflate_stored() for zero-length input
Index: zlib/ChangeLog.gcj
===
--- zlib/ChangeLog.gcj (revision 244761)
+++ zlib/ChangeLog.gcj (working copy)
@@ -1,3 +1,8 @@
+2017-01-22 Matthias Klose
+
+ * Import zlib 1.2.11.
+ * configure: Regenerate.
+
2017-01-13 Matthias Klose
* Import zlib 1.2.10.
Index: zlib/README
===
--- zlib/README (revision 244761)
+++ zlib/README (working copy)
@@ -3,7 +3,7 @@
ZLIB DATA COMPRESSION LIBRARY
-zlib 1.2.10 is a general purpose data compression library. All the code is
+zlib 1.2.11 is a general purpose data compression library. All the code is
thread safe. The data format used by the zlib library is described by RFCs
(Request for Comments) 1950 to 1952 in the files
http://tools.ietf.org/html/rfc1950 (zlib format), rfc1951 (deflate format) and
@@ -34,7 +34,7 @@
issue of Dr. Dobb's Journal; a copy of the article is available at
http://marknelson.us/1997/01/01/zlib-engine/ .
-The changes made in version 1.2.10 are documented in the file ChangeLog.
+The changes made in version 1.2.11 are documented in the file ChangeLog.
Unsupported third party contributions are provided in directory contrib/ .
Index: zlib/contrib/delphi/ZLib.pas
===
--- zlib/contrib/delphi/ZLib.pas (revision 244761)
+++ zlib/contrib/delphi/ZLib.pas (working copy)
@@ -152,7 +152,7 @@
const OutBuf: Pointer; BufSize: Integer);
const
- zlib_version = '1.2.10';
+ zlib_version = '1.2.11';
type
EZlibError = class(Exception);
Index: zlib/contrib/dotzlib/DotZLib/UnitTests.cs
===
--- zlib/contrib/dotzlib/DotZLib/UnitTests.cs (revision 244761)
+++ zlib/contrib/dotzlib/DotZLib/UnitTests.cs (working copy)
@@ -156,7 +156,7 @@
public void Info_Version()
{
Info info = new Info();
-Assert.AreEqual("1.2.10", Info.Version);
+Assert.AreEqual("1.2.11", Info.Version);
Assert.AreEqual(32, info.SizeOfUInt);
Assert.AreEqual(32, info.SizeOfULong);
Assert.AreEqual(32, info.SizeOfPointer);
Index: zlib/contrib/infback9/inftree9.c
===
--- zlib
Re: [patch] update zlib to the 1.2.10 release.
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
Re: [patch] update zlib to the 1.2.10 release.
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
Re: [patch] update zlib to the 1.2.10 release.
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
Re: [patch] update zlib to the 1.2.10 release.
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
Re: [patch] update zlib to the 1.2.10 release.
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
