[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #9 from Jeffrey A. Law  ---
Yaakov's patch has been installed as a local change while upstream figures out
they want to address in the long term.

[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771

--- Comment #8 from Jeffrey A. Law  ---
Author: law
Date: Wed Mar 15 05:01:23 2017
New Revision: 246152

URL: https://gcc.gnu.org/viewcvs?rev=246152=gcc=rev
Log:
2017-03-15  Yaakov Selkowitz 

PR bootstrap/79771
* gzguts.h (WIDECHAR): Do not define for __CYGWIN__.
* zlib.h (gzopen_w): Do not declare for __CYGWIN__.
* win32/zlib.def: Remove gzopen_w.

Modified:
trunk/zlib/ChangeLog.gcj
trunk/zlib/gzguts.h
trunk/zlib/win32/zlib.def
trunk/zlib/zlib.h

[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

[doko at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771

Matthias Klose  changed:

   What|Removed |Added

URL||https://github.com/madler/z
   ||lib/issues/238
 CC||doko at gcc dot gnu.org

--- Comment #7 from Matthias Klose  ---
now forwarded upstream

[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771

--- Comment #6 from Yaakov Selkowitz  ---
(In reply to Jakub Jelinek from comment #5)
> Do you really need even the zlib.def change?

For standalone zlib, yes; if you try to export a symbol which doesn't exist, ld
errors out.

> That part has been added 5 years ago, so it would surprise me if it didn't
> build even with that.

For standalone zlib, no, we've just been patching it out all this time.

Note that my patch was for the standalone zlib.  OTOH, in-tree zlib should be
built static-only, so zlib.def isn't used either way.

> If that works, the gzguts.h and zlib.h changes is something we can apply to
> gcc's copy until it is resolved upstream.

Ultimately, IMHO we should be encouraging --with-system-zlib on Cygwin (like
most other *NIX), but by all means, feel free to take the patch.

[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771

--- Comment #5 from Jakub Jelinek  ---
Do you really need even the zlib.def change?
That part has been added 5 years ago, so it would surprise me if it didn't
build even with that.
If that works, the gzguts.h and zlib.h changes is something we can apply to
gcc's copy until it is resolved upstream.

[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

[yselkowi at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771

--- Comment #4 from Yaakov Selkowitz  ---
This is an upstream issue in the recent zlib releases, here's a patch:

https://github.com/cygwinports/zlib/blob/master/1.2.11-gzopen_w.patch

Configuring with --with-system-zlib avoids this, as long as gcc doesn`t try
using the Win32-only gzopen_w on Cygwin (which it hasn't in the past).

[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

[daniel.santos at pobox dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771

--- Comment #3 from Daniel Santos  ---
I'm guessing that either they didn't test on Cygwin or they tested on a
pre-release version or I have some local/environmental issue, although my
environment was just recently generated.

Upstream is at 1.2.11 and the latest zlib available in Cygwin is 1.2.8-3, which
does not have this patch, but I am not an expert in Cygwin.  _wopen is an
ms-proprietary function and I presumed that it not being exported in Cygwin was
intentional, although I could be wrong.  It's probably a good idea to send it
upstream.

[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771

--- Comment #2 from Jakub Jelinek  ---
There is
https://github.com/madler/zlib/commit/b4ce6caf0992296230e4e25b22a63e418bdf4dcf
but not enough further info why it has changed.  So, report upstream?

[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
If this comes from upstream, then most likely upstream zlib doesn't build on
cygwin64 either.  So either you have too old cygwin and newer one supports it,
or it would be nice to figure out why this changed upstream.

[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
 Target||x86_64-pc-cygwin
  Component|regression  |bootstrap
   Target Milestone|--- |7.0
Summary|in-tree zlib breaks build   |[7 Regression] in-tree zlib
   ||breaks build