From owner-freebsd-current@FreeBSD.ORG Fri Apr 4 22:48:49 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52EFD9BF for ; Fri, 4 Apr 2014 22:48:49 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "theravensnest.org", Issuer "theravensnest.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CF16C2B for ; Fri, 4 Apr 2014 22:48:48 +0000 (UTC) Received: from [192.168.0.100] (cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52]) (authenticated bits=0) by theravensnest.org (8.14.7/8.14.7) with ESMTP id s34MmiaB076119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 Apr 2014 22:48:46 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Build failure due to block_abi.h From: David Chisnall In-Reply-To: <30EAFDFF-54AB-4318-95C6-F2BDC0329042@xcllnt.net> Date: Fri, 4 Apr 2014 23:48:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4396EF34-DFB3-4D2F-9BA1-00F05B5EC3EC@FreeBSD.org> References: <30EAFDFF-54AB-4318-95C6-F2BDC0329042@xcllnt.net> To: Marcel Moolenaar X-Mailer: Apple Mail (2.1874) Cc: "FreeBSD-CURRENT@freebsd.org Current" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 22:48:49 -0000 Hi Marcel, This error is a warning for me with gcc 4.7.3 when I try. With 4.2.1 in = the tree, it appears to be silenced by something (or possibly we're = using the native blocks code path with gcc and clang doesn't emit that = warning in non-blocks mode). We could pull out the structure = definitions - this is what I've done in the GNUstep versions of these = macros, which provide separate macros for declaring the type. It will = clutter the code a bit, but if it's not possible to silence the warnings = with your compiler then I can make that change. Unfortunately, the warning actually is spurious here - the structure = really is expected to be only for the scope of the function, because any = compiler that can actually generate those structure in a useful way will = give the type a different internal name. =20 I'll try to send you a patch to test tomorrow - in the meantime, = removing the -Werror should make it build. Unfortunately, gcc = (especially 4.2) doesn't provide very fine-grained control over warnings = and it doesn't seem to be possible (or, at least, not documented) to = disable the ones that are part of their default set. =20 David On 4 Apr 2014, at 18:42, Marcel Moolenaar wrote: > David, >=20 > The definition of DECLARE_BLOCK seems to trip over GCC 4.2.1 here > at Juniper. This is how we run the compiler: >=20 > = /volume/fwtools/gcc/jnpr/4.2.1/amd64-juniper-junos.5/bin/amd64-juniper-jun= os-gcc -O2 -pipe -I/b/marcelm/fbsd-head/src/lib/libc/include = -I/b/marcelm/fbsd-head/src/lib/libc/../../include = -I/b/marcelm/fbsd-head/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE = -I/b/marcelm/fbsd-head/src/lib/libc/../../contrib/gdtoa = -I/b/marcelm/fbsd-head/src/lib/libc/../../contrib/libc-vis -DINET6 = -I/b/marcelm/fbsd-head/obj/amd64/lib/libc = -I/b/marcelm/fbsd-head/src/lib/libc/resolv -D_ACL_PRIVATE = -DPOSIX_MISTAKE = -I/b/marcelm/fbsd-head/src/lib/libc/../../contrib/jemalloc/include = -I/b/marcelm/fbsd-head/src/lib/libc/../../contrib/tzcode/stdtime = -I/b/marcelm/fbsd-head/src/lib/libc/stdtime = -I/b/marcelm/fbsd-head/src/lib/libc/locale -DBROKEN_DES -DPORTMAP = -DDES_BUILTIN -I/b/marcelm/fbsd-head/src/lib/libc/rpc -DNS_CACHING = -DSYMBOL_VERSIONING -D__ELF__ -Dunix -D__unix -D__unix__ = -D__FreeBSD__=3D9 --sysroot = /volume/sisyphus/occam/sysroot/projects_tp5/20131031.611483/amd64 = -fno-builtin-printf -g -nostdinc = -isystem/b/marcelm/fbsd-head/obj/stage/amd64/usr/include = -isystem/b/marcelm/fbsd-head/obj/stage/amd64/include -std=3Dgnu99 = -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized = -Wno-pointer-sign -I/b/marcelm/fbsd-head/src/lib/libutil = -I/b/marcelm/fbsd-head/src/lib/msun/src = -I/b/marcelm/fbsd-head/src/lib/msun/x86 -c = /b/marcelm/fbsd-head/src/lib/libc/stdlib/atexit.c -o atexit.o > whatever set of flags we use here at Juniper: >=20 > This is the error: >=20 > Building /b/marcelm/fbsd-head/obj/amd64/lib/libc/atexit.o > cc1: warnings being treated as errors > /b/marcelm/fbsd-head/src/lib/libc/stdlib/atexit.c:144: warning: = anonymous struct declared inside parameter list > /b/marcelm/fbsd-head/src/lib/libc/stdlib/atexit.c:144: warning: its = scope is only this definition or declaration, which is probably not what = you want > *** Error code 1 >=20 > This hurdle is a bit higher than the hurdles I normally run into > when syncing with ^/head, so I could use your expertise. >=20 > We need to continue to be able to build the sources with compilers > outside of the tree as much as possible and I haven't found a way > yet (one I don't dislike to be precise) to get this blocks stuff > to compile. It's a huge blocker right now. >=20 > Thanks, >=20 > --=20 > Marcel Moolenaar > marcel@xcllnt.net >=20 >=20