Repository navigation
Python/dtoa.c:158: #error "Failed to find an exact-width 32-bit integer type" (FreeBSD 4.11 + gcc 2.95.4) #54261
Description
| BPO | 10052 |
|---|---|
| Nosy | @mdickinson, @ericvsmith, @tpn, @akitada, @skrah |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/mdickinson'
closed_at = <Date 2012-12-02.13:23:45.042>
created_at = <Date 2010-10-09.07:26:43.314>
labels = ['build']
title = 'Python/dtoa.c:158: #error "Failed to find an exact-width 32-bit integer type" (FreeBSD 4.11 + gcc 2.95.4)'
updated_at = <Date 2012-12-02.13:23:45.041>
user = 'https://github.com/akitada'bugs.python.org fields:
activity = <Date 2012-12-02.13:23:45.041>
actor = 'mark.dickinson'
assignee = 'mark.dickinson'
closed = True
closed_date = <Date 2012-12-02.13:23:45.042>
closer = 'mark.dickinson'
components = ['Build']
creation = <Date 2010-10-09.07:26:43.314>
creator = 'akitada'
dependencies = []
files = ['19254', '28185']
hgrepos = []
issue_num = 10052
keywords = ['patch']
message_count = 17.0
messages = ['118246', '118293', '118299', '118310', '118325', '118330', '118384', '118727', '118907', '120677', '176573', '176784', '176788', '176789', '176790', '176791', '176792']
nosy_count = 7.0
nosy_names = ['mark.dickinson', 'eric.smith', 'trent', 'akitada', 'skrah', 'Tom.OConnor', 'python-dev']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'patch review'
status = 'closed'
superseder = None
type = 'compile error'
url = 'https://bugs.python.org/issue10052'
versions = ['Python 2.7', 'Python 3.2', 'Python 3.3', 'Python 3.4']
Activity
akitada commentedon Oct 9, 2010
Building Python 2.7 fails on FreeBSD 4.11 with gcc 2.95.4 as below:
"""
gcc -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Python/dtoa.o Python/dtoa.c
Python/dtoa.c:158: #error "Failed to find an exact-width 32-bit integer type"
gmake: *** [Python/dtoa.o] Error 1
"""
This error occurs when HAVE_UINT32_T or HAVE_INT32_T are not defined.
Those constants are defined in Include/pyport.h as:
This doesn't work for FreeBSD 4, where exact-width integer types are defined #typedef and does not provide *_MAX for them.
I don't think this is the right fix but adding following macro to pyport.h fixed the problem.
mdickinson commentedon Oct 9, 2010
Thanks for the report. Some questions:
Have you tested this with Python 3.x at all? I'd expect the same issues to show up for Python 3.1 and 3.2.
Also, do you have the relevant configure output to hand? On my machine, the output from './configure' includes:
checking for uint32_t... yes
checking for uint64_t... yes
checking for int32_t... no
checking for int64_t... no
checking for ssize_t... yes
what do you get here? (Aside: those .... 'no's look odd to me; I think there may be an autoconf bug here.)
IIRC, the theory is that if stdint.h or inttypes.h #defines/typedefs uint32_t, then the UINT32_T_MAX macro should also be #defined somewhere in one of those header files; OTOH if neither stdint nor inttypes includes declarations for uint32_t then the configure script should find something suitable, and #define uint32_t.
akitada commentedon Oct 10, 2010
Yes, I can reproduce this in 2.7, 3.1 and 3.2.
Same here. It looks like a bug in autoconf:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560105
My output is below:
"""
checking for uint32_t... yes
checking for uint64_t... yes
checking for int32_t... no
checking for int64_t... no
checking for ssize_t... yes
"""
They are declared in inttypes.h.
typedef __int8_t int8_t;
typedef __int16_t int16_t;
typedef __int32_t int32_t;
typedef __int64_t int64_t;
typedef __uint8_t uint8_t;
typedef __uint16_t uint16_t;
typedef __uint32_t uint32_t;
typedef __uint64_t uint64_t;
typedef __intptr_t intptr_t;
typedef __uintptr_t uintptr_t;
#endif /* !SYS_INTTYPES_H */
"""
akitada commentedon Oct 10, 2010
Forgot to mention that there's no _MAX macro for exact-width integer types.
How about adding those macros when the system does not provide them?
skrah commentedon Oct 10, 2010
FreeBSD 5.0 has stdint.h, which includes machine/_stdint.h. In the
latter file the *_MAX constants are defined.
It looks like FreeBSD has had the correct setup for more than 7 years:
http://svn.freebsd.org/viewvc/base/release/5.0.0/sys/i386/include/
I would be moderately against making changes in Python for dated systems.
Could you perhaps just copy the files from 5.0?
akitada commentedon Oct 10, 2010
I understand FreeBSD 4.x is old platform (4.11, the last 4.x series, is released 5 years ago) but, in my opinion, as long as it does not make Python code cluttered, supporting old platforms is not that bad idea.
Anyway, I would like to leave the decision to the core developers.
mdickinson commentedon Oct 11, 2010
You mean the core developers other than Stefan? ;-)
I don't have any objection to a patch for this problem, provided that that patch is specifically targeted at FreeBSD 4, and clearly doesn't change behaviour on any other platform.
On one hand I agree that FreeBSD 4 isn't a high priority platform; on the other, it's not *that* obscure, and failure to build the Python core (rather than the extension modules) is quite a big deal. It's also a regression from 2.6, IIUC. And it should be easy to fix, with a single block of code in pyport.h.
TomOConnor commentedon Oct 14, 2010
Same problem on SGI IRIX 6.5.28 GCC 3.3.
Adding the following to pyport.h got me through as well.
akitada commentedon Oct 17, 2010
This patch is specifically targeted at FreeBSD 4.
tested on FreeBSD 4.11 and OS X 10.6.4
I don't know how to accommodate SGI IRIX's case.
mdickinson commentedon Nov 7, 2010
Thanks for the patch. This looks fine, in principle.
A couple of comments and questions:
(1) I think the patch should provide *MIN values alongside the *MAX values (for signed types only, of course).
(2) Are we sure that these values are valid on all FreeBSD 4 platforms, or should these definitions be further restricted to Free BSD 4 / x86?
(3) Are the types of the constants definitely correct? E.g., UINT64_MAX should have type uint64_t. That gets a bit tricky, since we can't use casts (which would prevent these constants being used in preprocessor #ifs), so we need to determine exactly what basic types uint32_t and uint64_t match, and make sure to use the correct suffix (e.g., ULL, LL, UL, L). For uint32_t I guess this is easy: it'll almost certainly be the same type as unsigned int. Is uint64_t defined as unsigned long long, or as unsigned long?
mdickinson commentedon Nov 28, 2012
This is also an issue on the Tru64 / alpha on Snakebite: that platform has inttypes.h but no stdint.h, and inttypes.h has typedefs for uint32_t and friends, but no defines for UINT32_MAX, etc. So the pyport.h check:
fails (uint32_t is a typedef rather than a #define). To make matters worse, the autoconf macro AC_TYPE_UINT32_T correctly detects that uint32_t exists, so doesn't bother to define it.
The ideal place to fix this would be in the configure scripts.
mdickinson commentedon Dec 2, 2012
Here's a patch (against the default branch). It adds simple AC_CHECK_TYPE configure-time typechecks for uint32_t and friends.
python-dev commentedon Dec 2, 2012
New changeset 6f9aba5f8d32 by Mark Dickinson in branch 'default':
bpo-10052: fix failed uint32_t / uint64_t / int32_t / int64_t detection on some platforms.
http://hg.python.org/cpython/rev/6f9aba5f8d32
mdickinson commentedon Dec 2, 2012
Committed to default. I want to look at the buildbot results and try some manual snakebite tests before deciding whether to backport.
python-dev commentedon Dec 2, 2012
New changeset 48fbe78167cd by Mark Dickinson in branch '2.7':
bpo-10052: fix failed uint32_t / uint64_t / int32_t / int64_t detection on some platforms.
http://hg.python.org/cpython/rev/48fbe78167cd
python-dev commentedon Dec 2, 2012
New changeset d82b73366227 by Mark Dickinson in branch '3.2':
bpo-10052: fix failed uint32_t / uint64_t / int32_t / int64_t detection on some platforms.
http://hg.python.org/cpython/rev/d82b73366227
New changeset 48de792747dc by Mark Dickinson in branch '3.3':
bpo-10052: merge fix from 3.2.
http://hg.python.org/cpython/rev/48de792747dc
New changeset 22d891a2d533 by Mark Dickinson in branch 'default':
bpo-10052: null merge from 3.3
http://hg.python.org/cpython/rev/22d891a2d533
mdickinson commentedon Dec 2, 2012
Fixed in all branches.