zlib build under 64 bit ios

[Stefan Csomor]

Hi

When building under ios 10.3 64-bit I run into missing lseek and friends, therefore it seems I have to add #include <unistd.h> to gzguts.h,

on the net I found a version that adds it as a an #else to this condition in line 38:

#if defined(__TURBOC__) || defined(_MSC_VER) || defined(_WIN32)
# include <io.h>
#else
# include <unistd.h>
#endif

does this seem reasonable, or is there a better place?

Thanks,

Stefan

[Vadim Zeitlin]

On Tue, 20 Jun 2017 17:50:26 +0000 Stefan Csomor wrote:

SC> When building under ios 10.3 64-bit I run into missing lseek and
SC> friends, therefore it seems I have to add #include <unistd.h> to
SC> gzguts.h,

It looks like lseek() is only used in gzlib.c, so maybe we should add the
inclusion of unistd.h (and sys/types.h?) there, to minimize the impact?

Also, even zlib is on GitHub nowadays, so it might be worth reporting the
problem at https://github.com/madler/zlib, ideally after checking that it's
not due to any changes done in our tree, of course.

Regards,
VZ

[Stefan Csomor]

Hi Vadim

> It looks like lseek() is only used in gzlib.c, so maybe we should add the
> inclusion of unistd.h (and sys/types.h?) there, to minimize the impact?

Unfortunately it’s not only lseek but also other functions like read and close in gzread

> Also, even zlib is on GitHub nowadays, so it might be worth reporting the
> problem at https://github.com/madler/zlib, ideally after checking that it's
> not due to any changes done in our tree, of course.

I’ve just downloaded the current release and I see there’s a bug in our version that has to be fixed anyway

“Due to the bug fixes, any installations of 1.2.9 or 1.2.10 should be immediately replaced with 1.2.11.”

should I update and commit the changes – directly or via pull request ?

Best,

Stefan

[Vadim Zeitlin]

On Wed, 21 Jun 2017 10:08:11 +0000 Stefan Csomor wrote:

SC> > Also, even zlib is on GitHub nowadays, so it might be worth reporting the
SC> > problem at https://github.com/madler/zlib, ideally after checking that it's
SC> > not due to any changes done in our tree, of course.
SC>
SC> I’ve just downloaded the current release and I see there’s a bug in our
SC> version that has to be fixed anyway
SC>
SC> “Due to the bug fixes, any installations of 1.2.9 or 1.2.10 should be
SC> immediately replaced with 1.2.11.”

FWIW I've looked at the changes and am almost sure this is not going to
fix the problem with missing unistd.h inclusion anyhow, there is nothing
relevant in "git diff v1.2.10 v1.2.11".

SC> should I update and commit the changes – directly or via pull request ?

Sure, let's update it. Unfortunately I don't think we have any up to date
instructions for doing this, the ones in
docs/contributing/how-to-update-third-party-library.md are still for svn
(and so need to be updated themselves...) and I'm not sure how did Cătălin
did this the last time (https://github.com/wxWidgets/wxWidgets/pull/380).

Ideally I'd like to switch to using submodules for third party libraries,
but, as usual, I don't have time to do this right now :-(

Thanks,
VZ

[Catalin]

On Wednesday, 21 June 2017, 15:05, Vadim Zeitlin wrote:

> I'm not sure how did Cătălin did this the last time.

IIRC this was the simplest 3rd party update, and it had no new or removed files. I think I looked at the files that were already in src/zlib/ and replaced them with the corresponding ones in the root folder of the zlib release.
The files that did the job AFAICS:
*.c
*.h
ChangeLog
README
zlib.3
zlib.map

Notice that there are a few new .c and .h files in zlib 1.2.11

Regards,
C

[Stefan Csomor]

Hi Vadim

SC> > Also, even zlib is on GitHub nowadays, so it might be worth reporting the
SC> > problem at https://github.com/madler/zlib, ideally after checking that it's
SC> > not due to any changes done in our tree, of course.
SC>
SC> I’ve just downloaded the current release and I see there’s a bug in our
SC> version that has to be fixed anyway
SC>
SC> “Due to the bug fixes, any installations of 1.2.9 or 1.2.10 should be
SC> immediately replaced with 1.2.11.”

FWIW I've looked at the changes and am almost sure this is not going to
fix the problem with missing unistd.h inclusion anyhow, there is nothing
relevant in "git diff v1.2.10 v1.2.11".

absolutely, it’s just a different issue I came across.

Regarding that compile issue:

I see that a configure in a fresh download changed zconf.h from

#ifdef HAVE_UNISTD_H /* may be set to #if 1 by ./configure */
# define Z_HAVE_UNISTD_H
#endif

#ifdef HAVE_STDARG_H /* may be set to #if 1 by ./configure */
# define Z_HAVE_STDARG_H
#endif

to

#if 1 /* was set to #if 1 by ./configure */
# define Z_HAVE_UNISTD_H
#endif

#if 1 /* was set to #if 1 by ./configure */
# define Z_HAVE_STDARG_H
#endif

and this makes things work correctly, so either we could change our own included zconf.h or add it to the defines somewhere in configure ? (where I would be totally at loss ) for xcode builds I could of course add it to wx.xcconfig

Best,

Stefan

[Vadim Zeitlin]

On Wed, 21 Jun 2017 14:37:10 +0000 Stefan Csomor wrote:

SC> Regarding that compile issue:
SC>
SC> I see that a configure in a fresh download changed zconf.h from
SC>
SC> #ifdef HAVE_UNISTD_H /* may be set to #if 1 by ./configure */
SC> # define Z_HAVE_UNISTD_H
SC> #endif
SC>
SC> #ifdef HAVE_STDARG_H /* may be set to #if 1 by ./configure */
SC> # define Z_HAVE_STDARG_H
SC> #endif
SC>
SC> to
SC>
SC> #if 1 /* was set to #if 1 by ./configure */
SC> # define Z_HAVE_UNISTD_H
SC> #endif
SC>
SC> #if 1 /* was set to #if 1 by ./configure */
SC> # define Z_HAVE_STDARG_H
SC> #endif
SC>
SC> and this makes things work correctly, so either we could change our own
SC> included zconf.h or add it to the defines somewhere in configure ?
SC> (where I would be totally at loss ) for xcode builds I could of course
SC> add it to wx.xcconfig

We could either run zlib configure under Unix, as we already do for
libtiff, it's not really difficult. Or we could add our own "#ifdef _WIN32"
etc to zconf.h, as we do for src/jpeg/jconfig.h.

Regards,
VZ