You receive this bug because the package in the ${summary} fails to compile if I set sys-devel/clang as default compiler. To reproduce this is issue: 1) emerge sys-devel/clang 2) declare CC=clang and CXX=clang++ into /etc/portage/env/clang 3) add "${package} clang" to /etc/portage/package.env # clang -v clang version 3.2 (tags/RELEASE_32/final) Target: x86_64-pc-linux-gnu Thread model: posix Additional info: Portage 2.1.11.31 (default/linux/amd64/13.0, gcc-4.6.3, glibc-2.15-r3, 3.2.38 x86_64) ================================================================= System uname: Linux-3.2.38-x86_64-QEMU_Virtual_CPU_version_1.2.2-with-gentoo-2.1 ld GNU ld (GNU Binutils) 2.22 app-shells/bash: 4.2_p37 dev-lang/python: 2.7.3-r2, 3.2.3 dev-util/pkgconfig: 0.27.1 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.69 sys-devel/automake: 1.11.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.6.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.6 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs collision-protect config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms sign split-log strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://192.168.2.3 http://distfiles.gentoo.org" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://192.168.2.3/gentoo-portage" USE="acl amd64 berkdb bindist bzip2 cli cracklib crypt cxx dri fortran gdbm gpm iconv ipv6 mmx modules mudflap multilib ncurses nls nptl openmp pam pcre readline session sse sse2 ssl tcpd unicode zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
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.
