Summary: | app-crypt/gnupg with sys-devel/clang - In file included from ../gl/stdint.h:66: /usr/include/inttypes.h:298:8: error: unknown type name 'intmax_t' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
Component: | Current packages | Assignee: | Crypto team [DISABLED] <crypto+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alonbl, alt, gaireg+bgo, nojspam, srcshelton, tamiko |
Priority: | Normal | Keywords: | LATER |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugs.g10code.com/gnupg/issue1547 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 408963 | ||
Attachments: |
build.log
portion of config.log failing for clang in "checking whether stdint.h conforms to C99" |
Description
Agostino Sarubbo
![]() Created attachment 339282 [details]
build.log
build log
Please work with upstream for these non standard configurations, we cannot support what upstream does not support. FWIW, just got the same error with clang 3.3. I also confirm this for clang-3.5, therefore changing summary. The error comes from the fact that upstream overrides <stdint.h> in "${s}"/gl/stdint.h by some sed trickery in "${S}"/gl/Makefile applied to the template "${S}"/gl/stdint_.h. This breaks compilation with clang in multiple ways (different for clang-3.2, clang-3.3). Replacing this generated stdint.h by a file just containing "#include_next<stdint.h>" fixes the compilation issues. But as this is security relevant code I refrain from recommending anything that is not approved by upstream :-] There seems to be an upstream bug [1] [1] https://bugs.g10code.com/gnupg/issue1547 the problem is: checking whether stdint.h conforms to C99... no then the ./gl/stdint_.h is used and defines intmax_t: #undef intmax_t #if @HAVE_LONG_LONG_INT@ && LONG_MAX >> 30 == 1 # define intmax_t long long int #elif defined int64_t # define intmax_t int64_t #else # define intmax_t long int #endif so we should have this symbol, but the include stdint.h is perform before this, so just maybe the stdint.h of clang is incomplete? or trace better the root cause? Created attachment 387360 [details] portion of config.log failing for clang in "checking whether stdint.h conforms to C99" No, clang provides a sufficient stdint.h - The problem is another one: ${S}/gl/stdint.h should never be generated in the first place! > checking whether stdint.h conforms to C99... no This it is!! The check in question is ${S}/gl/m4/stdint.m4: 69 dnl Now see whether we need a substitute <stdint.h>. Use 70 dnl ABSOLUTE_STDINT_H, not <stdint.h>, so that it also works during 71 dnl a "config.status --recheck" if a stdint.h has been 72 dnl created in the build directory. 73 if test $ac_cv_header_stdint_h = yes; then 74 AC_CACHE_CHECK([whether stdint.h conforms to C99], 75 [gl_cv_header_working_stdint_h], 76 [gl_cv_header_working_stdint_h=no 77 AC_COMPILE_IFELSE([ 78 AC_LANG_PROGRAM([[ [...] 192 ]])], 193 [gl_cv_header_working_stdint_h=yes])]) 194 fi Removing this check for a second (and assuming that clang is indeed C99 conforming - which it is :-)) results in a subtle change in ${S}/gl/Makefile: --- Makefile 2014-10-25 23:32:09.196122523 +0200 +++ Makefile 2014-10-25 23:59:34.994905572 +0200 @@ -253,4 +253,4 @@ SIZE_T_SUFFIX = ul -STDINT_H = stdint.h +STDINT_H = STRIP = SYS_SOCKET_H = With this, the fallback stdint.h under ${s}/gl/stdint.h is never generated and compilation succeeds (as happens for gcc). I ran into this issue as well on prefixed portage on OS X 10.11 (which only supports clang). gnupg-2.0.29-r1 fails with this error, but the details are slightly different. configure finds clang's copy of stdint.h: ///Library/Gentoo/usr/bin/../lib/clang/3.7.1/include/stdint.h instead of /usr/include/stdint.h. It correctly notes that clang's copy of stdint.h is not C99-compliant, but manages to include it anyway via the gl/stdint.h file. This article describes the issue (among others): http://blog.bitmelt.com/2014/06/compiling-gnupg-on-os-x.html I worked around the problem by changing the ebuild to invoke the compile step with: emake 'ABSOLUTE_STDINT_H="/usr/include/stdint.h"'. Do you want me to open another bug for this issue? Or should I just attach my emerge --info here? (In reply to John Gibson from comment #7) > Do you want me to open another bug for this issue? Or should I just attach > my emerge --info here? Please work directly with upstream[1] to resolve this issue, we try to avoid diverting from upstream. [1] https://bugs.gnupg.org/ (In reply to Alon Bar-Lev from comment #8) > > Please work directly with upstream[1] to resolve this issue, we try to avoid > diverting from upstream. > > [1] https://bugs.gnupg.org/ Upstream thinks that it's "a messed up toolchain installation" so I imagine that we'll get no help from that quarter. Unfortunately, I don't have the time to learn the details of the autotools search for stdint.h and the overall clang setup in prefixed portage to fix the issue myself. After https://github.com/gentoo/gentoo/commit/9807798754677b625d90625fc5b8f4136a60e7eb, all gnupg ebuilds compile for me with clang. You should have patched gnulib to detect that properly and send it to gnulib upstream. (In reply to Alon Bar-Lev from comment #11) > You should have patched gnulib to detect that properly and send it to gnulib > upstream. The fix was backported from the other gnupg ebuilds. That would be a better long term fix though. Feel free to file a new bug blocking 408963 and cc me. |