Failed to find a pointer-size integer type.

[adyshimony]

I am getting this error:

Unpacking download/zlib-1.2.11.tar.gz to build/zlib/ios-x86_64...
Using ar
Building static library libz.a version 1.2.11 with clang.
Checking for size_t... No.
Checking for long long... Yes.
Failed to find a pointer-size integer type.
** ./configure aborting.

[madler]

On what?

[adyshimony]

On building zlib as one of my project dependency.

[madler]

On what machine? What target? Operating system? Operating system version? Compiler version?

[adyshimony]

Mac book pro
MacOS high sierra
ios-x86_64 target, but all targets are failed.

clang compiler:
Apple LLVM version 9.1.0 (clang-902.0.39.1)
Target: x86_64-apple-darwin17.5.0
Thread model: posix

[madler]

I develop on a Mac and see no problem. How are you invoking configure?

[jakirkham]

Maybe the issue is the tests don't have #include <stddef.h>.

[madler]

It includes stdio.h, which defines size_t, so that's not it.

[jakirkham]

According to The Open Group it is defined in stddef.h. In stdio.h, they state size_t: As described in <stddef.h>.

It may be iOS (looks like what the user is building for) deviates from the standard by not including size_t in stdio.h. Don't know enough to say, but using stddef.h seems like a reasonable potential solution. Not sure what other options there are besides that given the simplicity of the test.

[wwp]

Any progress on this? I also get this error on MacOS 10.12 w/ Xcode 10.1 (clang-1000.11.45.5).

[madler]

I have the same versions of clang and Xcode as you do, and I see no problem and have never seen a problem. I develop zlib on a Mac. You will need to provide more information on exactly how you are invoking the problem, and exactly what problem you are seeing.

When I run ./configure, I get:

Checking for gcc...
Checking for shared library support...
Building shared library libz.1.2.11.dylib with gcc.
Checking for size_t... Yes.
Checking for off64_t... No.
Checking for fseeko... Yes.
Checking for strerror... Yes.
Checking for unistd.h... Yes.
Checking for stdarg.h... Yes.
Checking whether to use vs[n]printf() or s[n]printf()... using vs[n]printf().
Checking for vsnprintf() in stdio.h... Yes.
Checking for return value of vsnprintf()... Yes.
Checking for attribute(visibility) support... Yes.

And then it builds with no errors.

[wwp]

Here:
$ CC="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" ./configure --static --prefix=pwd/build

Building static library libz.a version 1.2.11 with /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang.
Checking for size_t... No.
Checking for long long... Yes.
Failed to find a pointer-size integer type.
** ./configure aborting.
make[1]: *** [src/Makefile] Error 1

I notice that with CC="/usr/bin/clang" or CC=gcc, the issue is not reproduced, which is strange because both this /usr/bin/clang as well as gcc and the /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin one report the same version using -v. I don't know what magic it's doing more, I must miss some information or knowledge about xcode uses.
Also note that the CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin comes from $QMAKE_CC, because I use Qt's 5.9's qmake to configure & build zlib during a complex build sequence.
Now that I use CC=gcc, it works fine. Not sure if qmake is doing something wrong or it's all about Xcode subtilities.

[madler]

Your command line that sets CC works fine for me. I get:

Building static library libz.a version 1.2.11.1-motley with /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang.
Checking for size_t... Yes.
Checking for off64_t... No.
Checking for fseeko... Yes.
Checking for strerror... Yes.
Checking for unistd.h... Yes.
Checking for stdarg.h... Yes.
Checking whether to use vs[n]printf() or s[n]printf()... using vs[n]printf().
Checking for vsnprintf() in stdio.h... Yes.
Checking for return value of vsnprintf()... Yes.
Checking for attribute(visibility) support... Yes.

In any case, this is not a zlib issue, so I am going to close it. You may want to look at the resulting configure.log file for clues as to what is going on.

[crargr]

I am sorry , I am having the same problem with Fedora and compiling with Intel. How was the issue solve?

[DimitriPapadopoulos]

According to The Open Group it is defined in stddef.h. In stdio.h, they state size_t: As described in <stddef.h>.

To fully quote the Open Group stdio.h page:

The following data types are defined through typedef:
[...]
size_t
As described in <stddef.h>.

It clearly means that size_t is defined in <stdio.h>.

Besides, that's in the C standard. All of these headers must define size_t:

• <stddef.h>
• <stdio.h>
• <stdlib.h>
• <string.h>
• <time.h>
• <uchar.h> (since C11)
• <wchar.h> (since C95)

[Neustradamus]

@ptoche has done another ticket here:

• Installation failed: Failed to find a pointer-size integer type. #494

@iii-i has done it:

• Linaro@d4b927b

@nmoinvaz has done it:
GerHobbelt@43d30f0

@rconde01 speaks about it here:

• [package] assimp/5.0.1: Transitive zlib dependency can target wrong archictecture conan-io/conan-center-index#3690