Home > Configure Error > Configure Error Cannot Find A Working 64-bit Integer Type

Configure Error Cannot Find A Working 64-bit Integer Type

But can you post your autoconf --version and automake --version? If dnl we found we need to use "long long int", better check. AC_NTA_CHECK_TYPE(uint8_t, unsigned char) AC_NTA_CHECK_TYPE(uint16_t, unsigned short) AC_NTA_CHECK_TYPE(uint32_t, unsigned int) dnl Checks for 64-bit integer types. Personal Open source Business Explore Sign up Sign in Pricing Blog Support Search GitHub This repository Watch 37 Star 362 Fork 235 mxe/mxe Code Issues 107 Pull requests 44 Projects http://outwardsound.com/configure-error/configure-error-cannot-determine-64-bit-integer-type.html

Adding the AC_PREREQ directive makes postgresql autoconf choose the right version, but before I'm submitting the PR I wanted to know why you removed the minimum version. no > checking whether long long int is 64 bits... Especially since they seem to be > adding more and more warnings that are harder and harder to work > around for issues that are less and less important. dnl FreeBSD 5.2 needs sys/socket.h included for net/if, and dnl needs sys/types.h for sys/sysctl.h and net/bpf.h dnl OpenBSD 3.9 needs sys/param.h included for sys/sysctl.h AC_CHECK_HEADERS([net/if.h sys/param.h sys/sysctl.h net/route.h net/if_dl.h],,, [ #include

Thanks! -- Igal Sapir Lucee Core Developer Lucee.org Next Message by Thread: Re: [HACKERS] Cannot find a working 64-bit integer type Robert Haas writes: > The relevant portion of config.log There is an entry in the parser Makefile to support this sort of use, which makes it look like my -Wno-error=unused-but-set-variable use would be redundant if it worked: # Latest flex Thanks! -- Igal Sapir Lucee Core Developer Lucee.org Responses Re: Cannot find a working 64-bit integer type at 2016-01-17 22:45:04 from Igal @ Lucee.org pgsql-hackers by date Next:From: Tom LaneDate: Thanks! -- Igal Sapir Lucee Core Developer Lucee.org Robert Haas Reply | Threaded Open this post in threaded view ♦ ♦ | Report Content as Inappropriate ♦ ♦ Re: Cannot

It's a supported state of the system and for the most part the Debian autoconf script works (as well as for 99% of MXE's packages, but fails for MXE itself). thx :) avih commented Apr 27, 2015 @mabrand ping? I don't know what to do about the execvp: No such file or directory problem. Yeah, that's a good thing to do.

I'm no expert but it seems to work. I know at least one way to make the script choose the new version, and that's by having a configure.ac file (even if it's empty). But your observation corresponds to my experience. AC_CHECK_FUNC([strlcat], [AC_DEFINE(HAVE_STRLCAT, 1, [Define to 1 if the C library includes the strlcat function])], [AC_LIBOBJ(strlcat)]) AC_CHECK_FUNC([strlcpy], [AC_DEFINE(HAVE_STRLCPY, 1, [Define to 1 if the C library includes the strlcpy function])], [AC_LIBOBJ(strlcpy)]) AC_CONFIG_FILES([Makefile])

regards, tom lane -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

vvv Home | News | Sitemap | FAQ | advertise | OSDir is It would be nice if someone could fix the test (and possibly later ones) so that it doesn't produce a warning/error when invoking the compiler, and it finds a 64-bit int Cool. Giving that many people build with CFLAGS="-O0 -g" on a day-to-day basis, which doesn't show some warnings, the folk wisdom might end up being: "Just before you submit your patch, see

I see no point in -Werror whatsoever. This should work: ./configure --prefix=/home/peter/pgsql CFLAGS="-Werror -Wno-error=unused-but-set-variable" However, it does not (with or without the -Wno-error): checking whether getpwuid_r takes a fifth argument... Terms Privacy Security Status Help You can't perform that action at this time. It would be nice if someone could fix the test (and possibly later ones) so that it doesn't produce a warning/error when invoking the compiler, and it finds a 64-bit int

AC_PROG_CC if test -n "$GCC"; then AC_DEFINE([ATTRIBUTE_UNUSED], [__attribute__ ((__unused__))], [Define to the compiler's unused pragma]) CFLAGS="$CFLAGS -Wall -Wshadow -Wwrite-strings" GCC_WEXTRA GCC_STACK_PROTECT_CC GCC_FORTIFY_SOURCE GCC_FORMAT_SECURITY dnl Uncomment the line below to compile with http://outwardsound.com/configure-error/configure-error-cannot-find-gconf-2-0.html Visit the Trac open source project athttp://trac.edgewall.org/ I'm clearly not the only one doing it this way, since src/backend/parser/gram.o manually sticks in -Wno-error... > gcc is not the only tool we use in the build process, so if Best, Stefan comment:5 in reply to: ↑ 3 ; follow-ups: ↓ 6 ↓ 9 Changed 8 years ago by plb Can you make sure that cpp works?

no > configure: error: Cannot find a working 64-bit integer type. > > Obviously it breaks this one configure test. Will you accept a PR for this patch? avih commented Apr 24, 2015 And indeed, when I navigate to the postgres build dir, I get this: ~/dev/mxe/tmp-postgresql-i686-w64-mingw32.static/postgresql-9.2.4 $ autoconf --version Autoconf version 2.13 --- Autoconf 2.13 chosen by Debian this contact form It would probably be really useful with a poor quality codebase though.

Free forum by Nabble Edit this page PostgreSQL › PostgreSQL - hackers Search everywhere only in this topic Advanced Search Setting -Werror in CFLAGS ‹ Previous Topic Next Topic › If we don't have them, use the replacement dnl functions from OpenBSD. Thanks again, Igal -- Sent via pgsql-hackers mailing list ([hidden email]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers Igal @ Lucee.org Reply | Threaded Open this post in threaded view ♦

avih referenced this issue Apr 29, 2015 Merged postgresql: require/hint minimum autoconf version 2.63 #674 avih commented Apr 29, 2015 FWIW, restoring the version warning which patch 1 removes wasn't enough

But feel free to research which ones. > As if to prove my point, I found this warning which I didn't > previously notice, just from 5 minutes of playing around: Hmm, I guess. The relevant portion of config.log seems to be this: configure:13285: gcc -o conftest.exe -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -O2 -I/home/Admin/sources/postgresql-9.5.0/src/include/port/win32 -DEXEC_BACKEND -Wl,--allow-multiple-definition -Wl,--disable-auto-import conftest.c -lz -lws2_32 Can you attach also the config.log from the CoinUtils?

He was right about that; I subsequently tried fairly hard to get the Flex guys to fix it a few months back, but it seems that Flex isn't that well maintained, Of course, it's not final yet, but it's pretty close. -- Sent via pgsql-hackers mailing list ([hidden email]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers Peter Eisentraut-2 Reply | Threaded Open I've tried this in the past, it's pretty difficult to make this work throughout. navigate here Anything that would make the error more specific would be fine :) Best, P comment:6 in reply to: ↑ 5 Changed 8 years ago by stefan Hi, Can you make sure that

Linux and {Free,Open}BSD do not. no configure: error: Cannot find a working 64-bit integer type. So apparently on your system configure fails the test for a 64-bit integer type because a #warning is emitted, and compiling with -Wno-cpp gets rid of that (probably without breaking anything AC_C_CONST AC_TYPE_SIZE_T AC_HEADER_TIME dnl Check for the uint{8,16,32}_t types and, if we don't have them, define dnl them using types which will work on most systems.

avih commented Apr 29, 2015 Yes, #674 fixes this issue. AC_MSG_CHECKING([for posix regular expression support]) AC_LINK_IFELSE([AC_LANG_PROGRAM([[ #include #include ]], [[regcomp(0, 0, 0); regexec(0, 0, 0, 0, 0)]])], [ac_nta_posix_regex=yes], [ac_nta_posic_regex=no]) AC_MSG_RESULT([$ac_nta_posix_regex]) if test $ac_nta_posix_regex = no; then AC_MSG_ERROR([You don't seem to dnl This breaks down into two steps: dnl (1) figure out if the compiler has a 64-bit int type with working dnl arithmetic, and if so dnl (2) see whether snprintf() Unimportant warnings that are easily avoidable are not so bad, but... -- Robert Haas EnterpriseDB: http://www.enterprisedb.comThe Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list ([hidden email]) To make changes to

According to 'man gcc': -Wno-cpp (C, Objective-C, C++, Objective-C++ and Fortran only) Suppress warning messages emitted by "#warning" directives. It seem to be a strange place for an exectuable to me. I'm enclosing the config.log of the successful run. It can get quite distressing.

That way, it could sort of become folk wisdom that you should build Postgres with those flags during development, and maybe even, on some limited basis, on the build farm, and However, I got it to work in 2 minutes by hacking up config.log. avih commented Apr 24, 2015 I think the offending commit is 513528c , and I don't see any explanation why the version enforcement was removed. Is /lib the location of the cpp that you tested?

Giving that many people build with CFLAGS="-O0 -g" on a day-to-day basis, which doesn't show some warnings, the folk wisdom might end up being: "Just before you submit your patch, see I'm also less than thrilled with the idea that whatever the gcc boys decide to make a warning tomorrow will automatically become a MUST FIX NOW for us. I tried several times. We are by far the most vigilant project I am aware of about fixing warnings.

Any ideas on how I can overcome this issue? configure.in:1089:PGAC_C_INLINE configure.in:1091:AC_C_FLEXIBLE_ARRAY_MEMBER configure.in:1092:PGAC_C_SIGNED configure.in:1093:AC_C_VOLATILE configure.in:1094:PGAC_C_FUNCNAME_SUPPORT configure.in:1095:PGAC_STRUCT_TIMEZONE configure.in:1096:PGAC_UNION_SEMUN configure.in:1097:PGAC_STRUCT_SOCKADDR_UN configure.in:1098:PGAC_STRUCT_SOCKADDR_STORAGE configure.in:1099:PGAC_STRUCT_SOCKADDR_STORAGE_MEMBERS configure.in:1100:PGAC_STRUCT_ADDRINFO configure.in:1101:AC_TYPE_INTPTR_T configure.in:1102:AC_TYPE_UINTPTR_T configure.in:1103:AC_TYPE_LONG_LONG_INT configure.in:1105:PGAC_TYPE_LOCALE_T configure.in:1107:AC_CHECK_TYPES([struct cmsgcred], [], [], configure.in:1113:AC_CHECK_TYPES([struct option], [], [], configure.in:1122: AC_CHECK_TYPE(z_streamp, [], [AC_MSG_ERROR([zlib version is too old