From owner-freebsd-toolchain@freebsd.org Sun Jul 30 05:16:51 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 417AFDAF03E for ; Sun, 30 Jul 2017 05:16:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 238DB65F15 for ; Sun, 30 Jul 2017 05:16:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: by mailman.ysv.freebsd.org (Postfix) id 1FA38DAF03D; Sun, 30 Jul 2017 05:16:51 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F40CDAF03B for ; Sun, 30 Jul 2017 05:16:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-86.reflexion.net [208.70.210.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D369565F13 for ; Sun, 30 Jul 2017 05:16:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22052 invoked from network); 30 Jul 2017 05:21:31 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 30 Jul 2017 05:21:31 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Sun, 30 Jul 2017 01:16:48 -0400 (EDT) Received: (qmail 16840 invoked from network); 30 Jul 2017 05:16:48 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Jul 2017 05:16:48 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 73FFBEC8BF3; Sat, 29 Jul 2017 22:16:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build From: Mark Millard In-Reply-To: <3E4B30BB-A9E5-480E-835D-DA6797FC230C@dsl-only.net> Date: Sat, 29 Jul 2017 22:16:46 -0700 Cc: toolchain@FreeBSD.org, Dimitry Andric Content-Transfer-Encoding: quoted-printable Message-Id: References: <201707272142.v6RLg1G4099900@beefy12.nyi.freebsd.org> <20170728135510.2c6de57f@kalimero.tijl.coosemans.org> <20170729015914.184c2660@kalimero.tijl.coosemans.org> <20170729212706.33841c4c@kalimero.tijl.coosemans.org> <20170729230641.6cecd29d@kalimero.tijl.coosemans.org> <3E4B30BB-A9E5-480E-835D-DA6797FC230C@dsl-only.net> To: Tijl Coosemans X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2017 05:16:51 -0000 [I oversimplified one point.] On 2017-Jul-29, at 3:24 PM, Mark Millard wrote: > On 2017-Jul-29, at 2:06 PM, Tijl Coosemans = wrote: >=20 >> On Sat, 29 Jul 2017 12:43:59 -0700 Mark Millard wrote: >>> On 2017-Jul-29, at 12:27 PM, Tijl Coosemans = wrote: >>>>> . . . >>>>=20 >>>> But none of this should be exposed to C++98 code. =20 >>>=20 >>> Only if the compiler is told to compile the code as >>> C++98 code or it is known that C++98 is the default >>> target version for the compiler. >>>=20 >>> The compiler command that you published as part of >>> the error report provides no such explicit control >>> of what language/library version rules are to be >>> used: >>>=20 >>> c++ -O2 -pipe -fstack-protector -fno-strict-aliasing -O2 -pipe = -fstack-protector -fno-strict-aliasing -DNDEBUG -Wall -W -Wcast-qual = -Wpointer-arith -Wcast-align -DUSE_C -DREVISION=3D8163 = -I/usr/local/include/SDL -I/usr/local/include -D_REENTRANT = -D_THREAD_SAFE -DCOLOUR_DEPTH=3D16 -c -MMD -o = build/default/squirrel/squirrel/sqvm.o squirrel/squirrel/sqvm.cc >>>=20 >>> So if the default is to compile for C++11 or later >>> the results of using the C++11 rules are the expected >>> results here. >>>=20 >>>> These names were not >>>> reserved in the C++98 standard so C++98 code is free to use them. = If >>>> libc++ cannot compile such valid C++98 code it is simply not = compliant >>>> with that standard. Note that in this case we were lucky to see a >>>> diagnostic. C++98 code may use these names in a way that doesn't = cause >>>> an error. Who's going to review our 27000 ports to make sure they = are >>>> still compiled correctly? =20 >>>=20 >>> Unless you tell the compiler to use C++98 rules you get the >>> rules of whatever version it targets by default. >>>=20 >>>>> For targeting -std=3Dc++11 or later in compiles >>>>> __enable_if and __is_arithemtic and __type >>>>> would be wrong in these places and require >>>>> code using the standard to use the names >>>>> that have the __ prefixes, in violation of >>>>> the standard's specifications. That includes >>>>> having no explicit -std=3D but depending on a >>>>> default that happens to end up with c++11 or >>>>> later as the version to target. =20 >>>>=20 >>>> Of course things like __enable_if are for internal use only. In = C++11 >>>> mode enable_if needs to be made available. =20 >>>=20 >>> And if the compiler default version target was >>> C++11 or later then what it did was what it should >>> have done. >>=20 >> Since you've written three times the same thing here let me reply = with >> three times the same thing: >=20 > Very true that I should not have bothered to try to > write something in all 3 places. >=20 > Your sequence gives additional information in each > of your 3 and so does not have my mistake. >=20 >> - Adding -std=3Dc++98 still fails to compile with the same errors. >>=20 >> - The compiler default is C++98: >> % c++ -x c++ -E -dM /dev/null | grep __cplusplus >> #define __cplusplus 199711L >>=20 >> - A quick look at the libc++ headers makes it immediately obvious = they >> expose and use C++11 features in C++98 mode. >>=20 >> And of course these were the very first things I checked before = writing >> my first email. >=20 > Good to know. >=20 > Under C++03 (and before) the basic requirements for macro names > are different (and matching what you are attempting): 17.4.3.1.1 > Macro Names says: >=20 > "A translation unit that includes a header shall not contain any = macros > that define names declared or defined in that header." >=20 > This greatly narrows the range of potential conflicts. >=20 > (But my understanding is that the rule was changed in part > because headers implicitly including content from other > standard headers is classified as okay in the early standards > as well and so overall the early standards were not fully > consistent, given how macros are specified to operate.) >=20 > There is the issue that even for C++03 and before: >=20 > "Clauses 18 through 27 do not specify the representation of classes > . . . An implementation may define static or non-static class members, > or both, as needed to implement the semantics of the member functions > specified in clauses 18 through 27." >=20 > So far as I know (unlike C) C++ makes no requirements that imply > the "extra" names involved in such must not be valid names in > programs, although it allows for such. (Such as using __ prefixes > or _ prefixes. Or for the global namespace: _ > prefixes. These are reserved but not required to be used by the > implementation from what I can tell.) So as far as I know > such "pollution" is an implementation quality issue but not a > standards conformance issue so long as the naming does not > mess up programs' use of the required naming from the standard. >=20 > So what you report about "type" being in use as an identifier > in the library of itself looks greatly unfortunate to me but also > does not seem to be a violation of the C++98, C++03, or other > standard versions. (Drat.) >=20 > I've also not found anything indicating that extra declarations > and definitions (such as from C++11 for compiles targeting C++98 > or C++03) would be a violation of a standard, such as C++98 or > C++03. (At least for any addition that does not prevent programs' > use of required aspects of the library.) >=20 > This was a surprise to me. But so far I've not found anything to > point to for a "this is wrong by the rules of the standard" > submittal against libc++. That makes it less likely to change in > the future. I should have noted two contexts that do explicitly specify that "names reserved to the implementation" be used: 17.4.4.7 Derived classes says both: "It is unspecified whether a class in the C++ Standard Library it itself derived from other classes (with names reserved to the implementation)." "It is unspecified whether a class described in the C++ Standard Library as derived from another class is derived from that class directly, or through other classes (with names reserved to the implementation) that are derived from the specified base class." These quotes are from ISO/EIC 14882:2003. More modern ones that I've looked at also include a 3rd context: "Implementations are permitted to provide addition predefined variables with names that are reserve to the implementation (5.10)." Otherwise having extra names is not restricted to using "names reserved to the implementation", even in C++98 and C++03 as far as I can tell. (I do not have a copy of the C++98 standard with me so I'm using C++03's instead.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Jul 30 20:35:08 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95AAADC1A00 for ; Sun, 30 Jul 2017 20:35:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-86.reflexion.net [208.70.210.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 582847FCCA for ; Sun, 30 Jul 2017 20:35:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15879 invoked from network); 30 Jul 2017 20:35:01 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 30 Jul 2017 20:35:01 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Sun, 30 Jul 2017 16:35:01 -0400 (EDT) Received: (qmail 1807 invoked from network); 30 Jul 2017 20:35:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Jul 2017 20:35:00 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 07911EC88F5; Sun, 30 Jul 2017 13:35:00 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: I have submitted bugzilla 221107 for a (e.g.) -r371706 system clang 5 vintage TARGET_ARCH=powerpc buildkernel failure for aha.kld: R_PPC_PLTREL24 reloc against local symbol Message-Id: <186BF66E-04E5-4663-AD0B-E07A9C631925@dsl-only.net> Date: Sun, 30 Jul 2017 13:34:59 -0700 To: Dimitry Andric , FreeBSD Toolchain , FreeBSD PowerPC ML , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2017 20:35:08 -0000 I experiment with system clang targeting powerpc (and powerpc64). Until recently I could buildkernel via system clang 4 (but it had problems if tried to boot such a kernel). After clang 5 it no longer completes the buildkernel. I'm submitting based on a -r371706 build attempt. The system binutils are in use. The technical material from the submittal is. . . First I list what the R_PPC_PLTREL24 is tied to then the error text then the build context. objdump reports that the .text+0x2b94 involved is in aha_isa_probe and is a reference to aha_alloc: (sorted objdump -x output:) 00002b78 R_PPC_PLTREL24 bus_alloc_resource 00002b88 R_PPC_PLTREL24 rman_get_start 00002b94 R_PPC_PLTREL24 aha_alloc 00002b96 R_PPC_ADDR32 .debug_str+0x0000266c 00002b9c R_PPC_PLTREL24 aha_probe 00002b9f R_PPC_ADDR32 .debug_str+0x00001904 (objdump -d --prefix-addresses output:) 00002aa4 mflr r0 . . . 00002b7c cmplwi r3,0 00002b80 stw r3,188(r28) 00002b84 beq 00002c1c 00002b88 bl 00002b88 00002b8c mr r3,r28 00002b90 mr r27,r4 00002b94 bl 00002b94 00002b98 mr r3,r28 00002b9c bl 00002b9c 00002ba0 cmplwi r3,0 --- all_subdir_aha --- Building = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG/m= odules/usr/src/sys/modules/aha/aha.kld . . . --- all_subdir_aha --- Building = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG/m= odules/usr/src/sys/modules/aha/aha.ko.full . . . --- aha.ko.full --- ld: aha.kld(.text+0x2b94): R_PPC_PLTREL24 reloc against local symbol aha.kld: could not read symbols: Bad value . . . --- all_subdir_aha --- *** [aha.ko.full] Error code 1 make[4]: stopped in /usr/src/sys/modules/aha .ERROR_TARGET=3D'aha.ko.full' = .ERROR_META_FILE=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys= /GENERICvtsc-NODBG/modules/usr/src/sys/modules/aha/aha.ko.full.meta' .MAKE.LEVEL=3D'4' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'ld -m elf32ppc_fbsd -Bshareable -znotext -d -warn-common = -o aha.ko.full aha.kld;' .CURDIR=3D'/usr/src/sys/modules/aha' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICv= tsc-NODBG/modules/usr/src/sys/modules/aha' .TARGETS=3D'all' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'powerpc' MACHINE_ARCH=3D'powerpc' = MAKEOBJDIRPREFIX=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys= /GENERICvtsc-NODBG/modules' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170720' --- all_subdir_agp --- Building = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG/m= odules/usr/src/sys/modules/agp/agp.ko.full --- all_subdir_aha --- = PATH=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/legacy/usr/= sbin:/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/legacy/usr/bin= :/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/legacy/bin:/usr/ob= j/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/usr/sbin:/usr/obj/powerpcv= tsc_clang/powerpc.powerpc/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bi= n' SRCTOP=3D'/usr/src' = OBJTOP=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvt= sc-NODBG/modules/usr/src' .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-host = /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null /usr/src/sys/modules/aha/Makefile = /usr/src/share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk /usr/src/sys/modules/aha/../Makefile.inc = /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk = /usr/src/share/mk/bsd.linker.mk /usr/src/sys/conf/kern.opts.mk = /usr/src/sys/conf/config.mk /usr/src/share/mk/bsd.links.mk = /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk = /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk = /usr/src/sys/conf/kern.mk' .PATH=3D'. /usr/src/sys/modules/aha /usr/src/sys/dev/aha = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG' 1 error make[4]: stopped in /usr/src/sys/modules/aha .ERROR_TARGET=3D'aha.ko.full' = .ERROR_META_FILE=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys= /GENERICvtsc-NODBG/modules/usr/src/sys/modules/aha/aha.ko.full.meta' .MAKE.LEVEL=3D'4' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'ld -m elf32ppc_fbsd -Bshareable -znotext -d -warn-common = -o aha.ko.full aha.kld;' .CURDIR=3D'/usr/src/sys/modules/aha' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICv= tsc-NODBG/modules/usr/src/sys/modules/aha' .TARGETS=3D'all' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'powerpc' MACHINE_ARCH=3D'powerpc' = MAKEOBJDIRPREFIX=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys= /GENERICvtsc-NODBG/modules' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170720' = PATH=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/legacy/usr/= sbin:/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/legacy/usr/bin= :/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/legacy/bin:/usr/ob= j/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/usr/sbin:/usr/obj/powerpcv= tsc_clang/powerpc.powerpc/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bi= n' SRCTOP=3D'/usr/src' = OBJTOP=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvt= sc-NODBG/modules/usr/src' .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-host = /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null /usr/src/sys/modules/aha/Makefile = /usr/src/share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk /usr/src/sys/modules/aha/../Makefile.inc = /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk = /usr/src/share/mk/bsd.linker.mk /usr/src/sys/conf/kern.opts.mk = /usr/src/sys/conf/config.mk /usr/src/share/mk/bsd.links.mk = /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk = /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk = /usr/src/sys/conf/kern.mk' .PATH=3D'. /usr/src/sys/modules/aha /usr/src/sys/dev/aha = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG' *** [all_subdir_aha] Error code 2 Build context: = ~/sys_build_scripts.amd64-host/make_powerpcvtsc_nodebug_clang_bootstrap-am= d64-host.sh -j8 buildworld buildkernel # more = ~/sys_build_scripts.amd64-host/make_powerpcvtsc_nodebug_clang_bootstrap-am= d64-host.sh=20 kldload -n filemon && \ script = ~/sys_typescripts/typescript_make_powerpcvtsc_nodebug_clang_bootstrap-amd6= 4-host-$(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-h= ost" \ WITH_META_MODE=3Dyes \ MAKEOBJDIRPREFIX=3D"/usr/obj/powerpcvtsc_clang" \ make $* C# more /root/src.configs/make.conf CFLAGS.gcc+=3D -v # more /root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-host TO_TYPE=3Dpowerpc # KERNCONF=3DGENERICvtsc-NODBG TARGET=3D${TO_TYPE} .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITHOUT_LLD=3D # lldb requires missing atomic 8-byte operations for powerpc (non-64) WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D # # Use WERROR to avoid stopping at the likes of: # error: implicit conversion from 'int' to 'int8_t' (aka 'signed char') = changes value from 128 to -128 [-Werror,-Wconstant-conversion] WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Jul 30 22:03:55 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86525DC3515 for ; Sun, 30 Jul 2017 22:03:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-86.reflexion.net [208.70.210.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4919782690 for ; Sun, 30 Jul 2017 22:03:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1477 invoked from network); 30 Jul 2017 22:03:53 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 30 Jul 2017 22:03:53 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Sun, 30 Jul 2017 18:03:53 -0400 (EDT) Received: (qmail 6574 invoked from network); 30 Jul 2017 22:03:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Jul 2017 22:03:53 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 8A0C0EC7ED7; Sun, 30 Jul 2017 15:03:52 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: I have submitted bugzilla 221107 for a (e.g.) -r321706 system clang 5 vintage TARGET_ARCH=powerpc buildkernel failure for aha.kld: R_PPC_PLTREL24 reloc against local symbol Date: Sun, 30 Jul 2017 15:03:51 -0700 References: <186BF66E-04E5-4663-AD0B-E07A9C631925@dsl-only.net> To: Dimitry Andric , FreeBSD Toolchain , FreeBSD PowerPC ML , FreeBSD Current In-Reply-To: <186BF66E-04E5-4663-AD0B-E07A9C631925@dsl-only.net> Message-Id: <636276E6-BA4C-4C28-84FF-A34BDF1F1702@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2017 22:03:55 -0000 [Just correcting the -r's to be -r321706.] On 2017-Jul-30, at 1:34 PM, Mark Millard wrote: I experiment with system clang targeting powerpc (and powerpc64). Until recently I could buildkernel via system clang 4 (but it had problems if tried to boot such a kernel). After clang 5 it no longer completes the buildkernel. I'm submitting based on a -r321706 build attempt. The system binutils are in use. The technical material from the submittal is. . . First I list what the R_PPC_PLTREL24 is tied to then the error text then the build context. objdump reports that the .text+0x2b94 involved is in aha_isa_probe and is a reference to aha_alloc: (sorted objdump -x output:) 00002b78 R_PPC_PLTREL24 bus_alloc_resource 00002b88 R_PPC_PLTREL24 rman_get_start 00002b94 R_PPC_PLTREL24 aha_alloc 00002b96 R_PPC_ADDR32 .debug_str+0x0000266c 00002b9c R_PPC_PLTREL24 aha_probe 00002b9f R_PPC_ADDR32 .debug_str+0x00001904 (objdump -d --prefix-addresses output:) 00002aa4 mflr r0 . . . 00002b7c cmplwi r3,0 00002b80 stw r3,188(r28) 00002b84 beq 00002c1c 00002b88 bl 00002b88 00002b8c mr r3,r28 00002b90 mr r27,r4 00002b94 bl 00002b94 00002b98 mr r3,r28 00002b9c bl 00002b9c 00002ba0 cmplwi r3,0 --- all_subdir_aha --- Building = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG/m= odules/usr/src/sys/modules/aha/aha.kld . . . --- all_subdir_aha --- Building = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG/m= odules/usr/src/sys/modules/aha/aha.ko.full . . . --- aha.ko.full --- ld: aha.kld(.text+0x2b94): R_PPC_PLTREL24 reloc against local symbol aha.kld: could not read symbols: Bad value . . . --- all_subdir_aha --- *** [aha.ko.full] Error code 1 make[4]: stopped in /usr/src/sys/modules/aha .ERROR_TARGET=3D'aha.ko.full' = .ERROR_META_FILE=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys= /GENERICvtsc-NODBG/modules/usr/src/sys/modules/aha/aha.ko.full.meta' .MAKE.LEVEL=3D'4' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'ld -m elf32ppc_fbsd -Bshareable -znotext -d -warn-common = -o aha.ko.full aha.kld;' .CURDIR=3D'/usr/src/sys/modules/aha' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICv= tsc-NODBG/modules/usr/src/sys/modules/aha' .TARGETS=3D'all' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'powerpc' MACHINE_ARCH=3D'powerpc' = MAKEOBJDIRPREFIX=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys= /GENERICvtsc-NODBG/modules' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170720' --- all_subdir_agp --- Building = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG/m= odules/usr/src/sys/modules/agp/agp.ko.full --- all_subdir_aha --- = PATH=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/legacy/usr/= sbin:/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/legacy/usr/bin= :/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/legacy/bin:/usr/ob= j/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/usr/sbin:/usr/obj/powerpcv= tsc_clang/powerpc.powerpc/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bi= n' SRCTOP=3D'/usr/src' = OBJTOP=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvt= sc-NODBG/modules/usr/src' .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-host = /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null /usr/src/sys/modules/aha/Makefile = /usr/src/share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk /usr/src/sys/modules/aha/../Makefile.inc = /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk = /usr/src/share/mk/bsd.linker.mk /usr/src/sys/conf/kern.opts.mk = /usr/src/sys/conf/config.mk /usr/src/share/mk/bsd.links.mk = /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk = /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk = /usr/src/sys/conf/kern.mk' .PATH=3D'. /usr/src/sys/modules/aha /usr/src/sys/dev/aha = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG' 1 error make[4]: stopped in /usr/src/sys/modules/aha .ERROR_TARGET=3D'aha.ko.full' = .ERROR_META_FILE=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys= /GENERICvtsc-NODBG/modules/usr/src/sys/modules/aha/aha.ko.full.meta' .MAKE.LEVEL=3D'4' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'ld -m elf32ppc_fbsd -Bshareable -znotext -d -warn-common = -o aha.ko.full aha.kld;' .CURDIR=3D'/usr/src/sys/modules/aha' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICv= tsc-NODBG/modules/usr/src/sys/modules/aha' .TARGETS=3D'all' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'powerpc' MACHINE_ARCH=3D'powerpc' = MAKEOBJDIRPREFIX=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys= /GENERICvtsc-NODBG/modules' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170720' = PATH=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/legacy/usr/= sbin:/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/legacy/usr/bin= :/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/legacy/bin:/usr/ob= j/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/usr/sbin:/usr/obj/powerpcv= tsc_clang/powerpc.powerpc/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bi= n' SRCTOP=3D'/usr/src' = OBJTOP=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvt= sc-NODBG/modules/usr/src' .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-host = /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null /usr/src/sys/modules/aha/Makefile = /usr/src/share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk /usr/src/sys/modules/aha/../Makefile.inc = /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk = /usr/src/share/mk/bsd.linker.mk /usr/src/sys/conf/kern.opts.mk = /usr/src/sys/conf/config.mk /usr/src/share/mk/bsd.links.mk = /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk = /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk = /usr/src/sys/conf/kern.mk' .PATH=3D'. /usr/src/sys/modules/aha /usr/src/sys/dev/aha = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG' *** [all_subdir_aha] Error code 2 Build context: = ~/sys_build_scripts.amd64-host/make_powerpcvtsc_nodebug_clang_bootstrap-am= d64-host.sh -j8 buildworld buildkernel # more = ~/sys_build_scripts.amd64-host/make_powerpcvtsc_nodebug_clang_bootstrap-am= d64-host.sh=20 kldload -n filemon && \ script = ~/sys_typescripts/typescript_make_powerpcvtsc_nodebug_clang_bootstrap-amd6= 4-host-$(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-h= ost" \ WITH_META_MODE=3Dyes \ MAKEOBJDIRPREFIX=3D"/usr/obj/powerpcvtsc_clang" \ make $* C# more /root/src.configs/make.conf CFLAGS.gcc+=3D -v # more /root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-host TO_TYPE=3Dpowerpc # KERNCONF=3DGENERICvtsc-NODBG TARGET=3D${TO_TYPE} .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITHOUT_LLD=3D # lldb requires missing atomic 8-byte operations for powerpc (non-64) WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D # # Use WERROR to avoid stopping at the likes of: # error: implicit conversion from 'int' to 'int8_t' (aka 'signed char') = changes value from 128 to -128 [-Werror,-Wconstant-conversion] WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon Jul 31 08:57:20 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63D75DCDA18 for ; Mon, 31 Jul 2017 08:57:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-86.reflexion.net [208.70.210.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C4DD6E61B for ; Mon, 31 Jul 2017 08:57:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8211 invoked from network); 31 Jul 2017 09:02:02 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 31 Jul 2017 09:02:02 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Mon, 31 Jul 2017 04:57:18 -0400 (EDT) Received: (qmail 31534 invoked from network); 31 Jul 2017 08:57:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 31 Jul 2017 08:57:18 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 45294EC7ED7; Mon, 31 Jul 2017 01:57:17 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: libstdc++ build failures on MIPS, PowerPC, Sparc Date: Mon, 31 Jul 2017 01:57:16 -0700 References: <1652170A-4809-4C0C-AA9D-3C364EA3866B@FreeBSD.org> <995425D0-1240-4008-8BF7-982C7725353C@dsl-only.net> <0A3348B1-0D56-4D68-9839-292635C6610D@dsl-only.net> <5AF488C1-FC10-4113-A882-8865C3FEDD11@dsl-only.net> To: Bryan Drewery , FreeBSD PowerPC ML , rpokala@mac.com, FreeBSD Current , FreeBSD Toolchain In-Reply-To: <5AF488C1-FC10-4113-A882-8865C3FEDD11@dsl-only.net> Message-Id: <07FE9513-BCB7-4955-A01B-7E17D6AA825D@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 08:57:20 -0000 [Fixed by -r321684 .] On 2017-Jul-24, at 2:31 AM, Mark Millard wrote: > [I'm just sending the notes to Bryan Drewery, no new > information added.] >=20 >=20 > Ravi Pokala rpokala at mac.com wrote on > Sun Jul 23 19:44:57 UTC 2017 : >=20 >> I did a tinderbox build of -HEAD as of r321376; there were failures = like this (paths shortened): >>=20 >> c++ -isystem ${OUTDIR}/tmp/usr/include/c++/v1 -std=3Dc++11 = -nostdinc++ -isystem ${OUTDIR}/tmp/usr/include -L${OUTDIR}/tmp/usr/lib = -B${OUTDIR}/tmp/usr/lib --sysroot=3D${OUTDIR}/tmp = -B${OUTDIR}/tmp/usr/bin -O -pipe -G0 -EB -mabi=3D32 -msoft-float = -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I${SRCDIR}/gnu/lib/libstdc++ = -I${SRCDIR}/contrib/libstdc++/libsupc++ -I${SRCDIR}/contrib/gcc = -I${SRCDIR}/contrib/libstdc++/include = -I${SRCDIR}/contrib/gcclibs/include = -I${SRCDIR}/contrib/libstdc++/include -I. = -frandom-seed=3DRepeatabilityConsideredGood = -fno-implicit-templates -ffunction-sections -fdata-sections = -Wno-deprecated -c ${SRCDIR}/contrib/libstdc++/src/bitmap_allocator.cc = -o bitmap_allocator.o >>=20 >> cc1plus: error: unrecognized command line option "-std=3Dc++11" >> *** [bitmap_allocator.o] Error code 1 >>=20 >> on multiple worlds: >>=20 >> [threepio:clean/base/head] rpokala% egrep -l 'stopped in .*libstdc' = _.*buildworld >> _.mips.mips.buildworld >> _.mips.mips64.buildworld >> _.mips.mips64el.buildworld >> _.mips.mips64elhf.buildworld >> _.mips.mips64hf.buildworld >> _.mips.mipsel.buildworld >> _.mips.mipselhf.buildworld >> _.mips.mipshf.buildworld >> _.mips.mipsn32.buildworld >> _.powerpc.powerpc.buildworld >> _.powerpc.powerpc64.buildworld >> _.powerpc.powerpcspe.buildworld >> _.sparc64.sparc64.buildworld >>=20 >> No interesting build environment, just MAKEOBJDIRPREFIX and JFLAGS; = clean sources and empty output directory. . . . My recent tests of building powerpc and powerpc64 gcc 4.2.1 style indicate that -r321684 has fixed this issue. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon Jul 31 11:59:09 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A0B3DD1413 for ; Mon, 31 Jul 2017 11:59:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6F1CA740CD for ; Mon, 31 Jul 2017 11:59:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v6VBx9aT015253 for ; Mon, 31 Jul 2017 11:59:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 220590] math/fftw3: fails to build on armv6 (729 ports skipped) Date: Mon, 31 Jul 2017 11:59:09 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-patch, regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jhale@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 11:59:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220590 --- Comment #10 from commit-hook@freebsd.org --- A commit references this bug: Author: jhale Date: Mon Jul 31 11:58:28 UTC 2017 New revision: 446955 URL: https://svnweb.freebsd.org/changeset/ports/446955 Log: Fix build on armv6. The -funsafe-math-optimizations flag in Clang (pulled= in by -ffast-math) is emitting references to the sincos() function which is not implemented on versions of FreeBSD < 1200032. Workaround by adding -fno-unsafe-math-optimizations to armv6 CFLAGS. /bin/sh ../libtool --tag=3DCC --mode=3Dlink /nxb-bin/usr/bin/cc -D_THR= EAD_SAFE -pthread -O2 -pipe -O3 -ffast-math -fstrict-aliasing -fomit-frame-pointer = -o bench bench-bench.o bench-hook.o bench-fftw-bench.o ../threads/libfftw3_threads.la ../libfftw3.la ../libbench2/libbench2.a -lm libtool: link: /nxb-bin/usr/bin/cc -D_THREAD_SAFE -pthread -O2 -pipe -O3 -ffast-math -fstrict-aliasing -fomit-frame-pointer -o .libs/bench bench-ben= ch.o bench-hook.o bench-fftw-bench.o ../threads/.libs/libfftw3_threads.so ../.libs/libfftw3.so ../libbench2/libbench2.a -lm -pthread -Wl,-rpath -Wl,/usr/local/lib ./libbench2/libbench2.a(verify-lib.o): In function `aphase_shift': verify-lib.c:(.text+0x578): undefined reference to `sincos' ./libbench2/libbench2.a(verify-lib.o): In function `tf_shift': verify-lib.c:(.text+0x13a0): undefined reference to `sincos' verify-lib.c:(.text+0x16e4): undefined reference to `sincos' cc: error: linker command failed with exit code 1 (use -v to see invocati= on) gmake[3]: *** [Makefile:400: bench] Error 1 gmake[3]: Leaving directory '/wrkdirs/usr/ports/math/fftw3/work/fftw-3.3.6-pl2/tests' gmake[2]: *** [Makefile:684: all-recursive] Error 1 gmake[2]: Leaving directory '/wrkdirs/usr/ports/math/fftw3/work/fftw-3.3.6-pl2' gmake[1]: *** [Makefile:549: all] Error 2 gmake[1]: Leaving directory '/wrkdirs/usr/ports/math/fftw3/work/fftw-3.3.6-pl2' *** Error code 1 PR: 220590 Submitted by: jbeich Changes: head/math/fftw3/Makefile --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Jul 31 12:06:54 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6D76DAB0F1 for ; Mon, 31 Jul 2017 12:06:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A46C274870 for ; Mon, 31 Jul 2017 12:06:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v6VC6sto004655 for ; Mon, 31 Jul 2017 12:06:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 220590] math/fftw3: fails to build on armv6 (729 ports skipped) Date: Mon, 31 Jul 2017 12:06:54 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-patch, regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhale@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jhale@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 12:06:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220590 Jason E. Hale changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed Resolution|--- |FIXED --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Jul 31 12:17:25 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 157FEDAB4CA for ; Mon, 31 Jul 2017 12:17:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0276374F6C for ; Mon, 31 Jul 2017 12:17:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v6VCHOb2006508 for ; Mon, 31 Jul 2017 12:17:24 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 220590] math/fftw3: fails to build on armv6 (729 ports skipped) Date: Mon, 31 Jul 2017 12:17:25 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-patch, regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jhale@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 12:17:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220590 --- Comment #11 from commit-hook@freebsd.org --- A commit references this bug: Author: jhale Date: Mon Jul 31 12:16:28 UTC 2017 New revision: 446956 URL: https://svnweb.freebsd.org/changeset/ports/446956 Log: MFH: r446955 Fix build on armv6. The -funsafe-math-optimizations flag in Clang (pulled= in by -ffast-math) is emitting references to the sincos() function which is not implemented on versions of FreeBSD < 1200032. Workaround by adding -fno-unsafe-math-optimizations to armv6 CFLAGS. /bin/sh ../libtool --tag=3DCC --mode=3Dlink /nxb-bin/usr/bin/cc -D_THR= EAD_SAFE -pthread -O2 -pipe -O3 -ffast-math -fstrict-aliasing -fomit-frame-pointer = -o bench bench-bench.o bench-hook.o bench-fftw-bench.o ../threads/libfftw3_threads.la ../libfftw3.la ../libbench2/libbench2.a -lm libtool: link: /nxb-bin/usr/bin/cc -D_THREAD_SAFE -pthread -O2 -pipe -O3 -ffast-math -fstrict-aliasing -fomit-frame-pointer -o .libs/bench bench-ben= ch.o bench-hook.o bench-fftw-bench.o ../threads/.libs/libfftw3_threads.so ../.libs/libfftw3.so ../libbench2/libbench2.a -lm -pthread -Wl,-rpath -Wl,/usr/local/lib ./libbench2/libbench2.a(verify-lib.o): In function `aphase_shift': verify-lib.c:(.text+0x578): undefined reference to `sincos' ./libbench2/libbench2.a(verify-lib.o): In function `tf_shift': verify-lib.c:(.text+0x13a0): undefined reference to `sincos' verify-lib.c:(.text+0x16e4): undefined reference to `sincos' cc: error: linker command failed with exit code 1 (use -v to see invocati= on) gmake[3]: *** [Makefile:400: bench] Error 1 gmake[3]: Leaving directory '/wrkdirs/usr/ports/math/fftw3/work/fftw-3.3.6-pl2/tests' gmake[2]: *** [Makefile:684: all-recursive] Error 1 gmake[2]: Leaving directory '/wrkdirs/usr/ports/math/fftw3/work/fftw-3.3.6-pl2' gmake[1]: *** [Makefile:549: all] Error 2 gmake[1]: Leaving directory '/wrkdirs/usr/ports/math/fftw3/work/fftw-3.3.6-pl2' *** Error code 1 PR: 220590 Submitted by: jbeich Approved by: ports-secteam (blanket) Changes: _U branches/2017Q3/ branches/2017Q3/math/fftw3/Makefile --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Jul 31 19:44:05 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77680DBC04C for ; Mon, 31 Jul 2017 19:44:05 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 44B6C65A4B for ; Mon, 31 Jul 2017 19:44:05 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 44012DBC04B; Mon, 31 Jul 2017 19:44:05 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43924DBC04A for ; Mon, 31 Jul 2017 19:44:05 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay107.isp.belgacom.be (mailrelay107.isp.belgacom.be [195.238.20.134]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9659265A4A; Mon, 31 Jul 2017 19:44:04 +0000 (UTC) (envelope-from tijl@freebsd.org) X-Belgacom-Dynamic: yes IronPort-PHdr: =?us-ascii?q?9a23=3A5rpfNRZ34t5QQyPiDtWhIgH/LSx+4OfEezUN459i?= =?us-ascii?q?sYplN5qZr8S/bnLW6fgltlLVR4KTs6sC0LuG9fi4EUU7or+5+EgYd5JNUxJXwe?= =?us-ascii?q?43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQviPgRp?= =?us-ascii?q?OOv1BpTSj8Oq3Oyu5pHfeQtFiT6+bL9oMBm6sRjau9ULj4dlNqs/0AbCrGFSe+?= =?us-ascii?q?RRy2NoJFaTkAj568yt4pNt8Dletuw4+cJYXqr0Y6o3TbpDDDQ7KG81/9HktQPC?= =?us-ascii?q?TQSU+HQRVHgdnwdSDAjE6BH6WYrxsjf/u+Fg1iSWIdH6QLYpUjm58axlVAHnhz?= =?us-ascii?q?sGNz4h8WHYlMpwjL5AoBm8oxBz2pPYbJ2JOPZ7eK7WYNEUSndbXstJWSJPAp2y?= =?us-ascii?q?YZYMAeUDM+ZXoJXyqVQVoBuiBwSgGP/jxiNUinPo26AxzuQvERvB3AwlB98Arn?= =?us-ascii?q?XUrNfxNKwPT+21y67IzS7dYPNTwzj97pPIeQ0mrPGQXLJwc87RxFIvGQPfkFqf?= =?us-ascii?q?t5HoMS6b2OgXtGib9eVgWPuphmU6pQ9xpT2vyd0tionPno8VxErE+jtnz4kuPt?= =?us-ascii?q?23VVR3Ydm+EJtfry2VKpB2Qsc7T2FvviY6zr0HtYS9fCcU1JQqwQPUZf+fc4WQ?= =?us-ascii?q?4R/vSfydLSl3iX9lYr6zmhS//Ey6xuHhVMS4zFBHpTdfnNbWrHACzRnT59CCSv?= =?us-ascii?q?t640iuxy6C1xvW6uFYOUA0krfbK4I5zr4wiJUTtUPDEzf1mErsiK+Wd0Ak9fay?= =?us-ascii?q?6+TgeLnmup6cN41wig3kLqsuncu/Af8mPQgLRWeb//+82Kfk/U3jT7VGlvw2kq?= =?us-ascii?q?/Hv5DGPckWpbO1DxVL3oss6xuzFSqq3dYckHUdMV5Ieg6Lg5DsO17UIfD4Cfm/?= =?us-ascii?q?g06rkDdu3/3GIrzhApfJLnXYnrfhZ6hy5FBHxwoo0N9T/ZVUCqsOIP7rQE/+qM?= =?us-ascii?q?TYDgMlMwyz2+voFdR91oYFVGKBGK+WLr3dvkST5u0yOeWMY5UVuDnlIfg/+/Hu?= =?us-ascii?q?lWM5mUMafaSxwZsXb3e4HvB6LEWZe3Xsg9EBHHwEvgokUuPllkaNUSVOaHqoWK?= =?us-ascii?q?I8/D47W8qaCtLmT5quyJmA2COyBJEeMmVPEFOJEF/kbIHBXPEIeWSUL9M3wRIe?= =?us-ascii?q?Ur30d44j0VmFswjhxr9uKPGcrjEZt5bL+sJ46sfouVc17zMiXJfV6H2EU2whxj?= =?us-ascii?q?BAfDQxxq0q5BUlklo=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2AdBQBuh39Z/6qz9VFcGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBFAEBAQEBAQEBAQEBBwEBAQEBgy9UEIEUjwCPBgGBay0BlV0OggQ?= =?us-ascii?q?khSMChAdBFwEBAQEBAQEBAQEBaiiCMyQBgkEBBTocIxALGAklDyoeBhOKM7Bdi?= =?us-ascii?q?0QBAQEBAQEBAwEBAQEBI4MoiFWEQQESAYYTBYlhiGyNIodPg0wFiHp8gXSPWpV?= =?us-ascii?q?yIQMzfwtTMQiGFIFQPjaHfoIxAQEB?= X-IPAS-Result: =?us-ascii?q?A2AdBQBuh39Z/6qz9VFcGQEBAQEBAQEBAQEBBwEBAQEBFAE?= =?us-ascii?q?BAQEBAQEBAQEBBwEBAQEBgy9UEIEUjwCPBgGBay0BlV0OggQkhSMChAdBFwEBA?= =?us-ascii?q?QEBAQEBAQEBaiiCMyQBgkEBBTocIxALGAklDyoeBhOKM7Bdi0QBAQEBAQEBAwE?= =?us-ascii?q?BAQEBI4MoiFWEQQESAYYTBYlhiGyNIodPg0wFiHp8gXSPWpVyIQMzfwtTMQiGF?= =?us-ascii?q?IFQPjaHfoIxAQEB?= Received: from 170.179-245-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.245.179.170]) by relay.skynet.be with ESMTP; 31 Jul 2017 21:42:52 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.15.2/8.15.2) with ESMTP id v6VJgpOv012592; Mon, 31 Jul 2017 21:42:52 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Mon, 31 Jul 2017 21:42:51 +0200 From: Tijl Coosemans To: Mark Millard Cc: toolchain@FreeBSD.org, Dimitry Andric Subject: Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build Message-ID: <20170731214251.0a5de99b@kalimero.tijl.coosemans.org> In-Reply-To: References: <201707272142.v6RLg1G4099900@beefy12.nyi.freebsd.org> <20170728135510.2c6de57f@kalimero.tijl.coosemans.org> <20170729015914.184c2660@kalimero.tijl.coosemans.org> <20170729212706.33841c4c@kalimero.tijl.coosemans.org> <20170729230641.6cecd29d@kalimero.tijl.coosemans.org> <3E4B30BB-A9E5-480E-835D-DA6797FC230C@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 19:44:05 -0000 On Sat, 29 Jul 2017 22:16:46 -0700 Mark Millard wrote: > On 2017-Jul-29, at 3:24 PM, Mark Millard wrote: >> On 2017-Jul-29, at 2:06 PM, Tijl Coosemans wrote: >>> - Adding -std=c++98 still fails to compile with the same errors. >>> >>> - The compiler default is C++98: >>> % c++ -x c++ -E -dM /dev/null | grep __cplusplus >>> #define __cplusplus 199711L >>> >>> - A quick look at the libc++ headers makes it immediately obvious they >>> expose and use C++11 features in C++98 mode. >>> >>> And of course these were the very first things I checked before writing >>> my first email. >> >> Good to know. >> >> Under C++03 (and before) the basic requirements for macro names >> are different (and matching what you are attempting): 17.4.3.1.1 >> Macro Names says: >> >> "A translation unit that includes a header shall not contain any macros >> that define names declared or defined in that header." >> >> This greatly narrows the range of potential conflicts. >> >> (But my understanding is that the rule was changed in part >> because headers implicitly including content from other >> standard headers is classified as okay in the early standards >> as well and so overall the early standards were not fully >> consistent, given how macros are specified to operate.) >> >> There is the issue that even for C++03 and before: >> >> "Clauses 18 through 27 do not specify the representation of classes >> . . . An implementation may define static or non-static class members, >> or both, as needed to implement the semantics of the member functions >> specified in clauses 18 through 27." >> >> So far as I know (unlike C) C++ makes no requirements that imply >> the "extra" names involved in such must not be valid names in >> programs, although it allows for such. (Such as using __ prefixes >> or _ prefixes. Or for the global namespace: _ >> prefixes. These are reserved but not required to be used by the >> implementation from what I can tell.) So as far as I know >> such "pollution" is an implementation quality issue but not a >> standards conformance issue so long as the naming does not >> mess up programs' use of the required naming from the standard. >> >> So what you report about "type" being in use as an identifier >> in the library of itself looks greatly unfortunate to me but also >> does not seem to be a violation of the C++98, C++03, or other >> standard versions. (Drat.) >> >> I've also not found anything indicating that extra declarations >> and definitions (such as from C++11 for compiles targeting C++98 >> or C++03) would be a violation of a standard, such as C++98 or >> C++03. (At least for any addition that does not prevent programs' >> use of required aspects of the library.) >> >> This was a surprise to me. But so far I've not found anything to >> point to for a "this is wrong by the rules of the standard" >> submittal against libc++. That makes it less likely to change in >> the future. > > I should have noted two contexts that do explicitly specify that > "names reserved to the implementation" be used: > > 17.4.4.7 Derived classes says both: > > "It is unspecified whether a class in the C++ Standard Library it > itself derived from other classes (with names reserved to the > implementation)." > > "It is unspecified whether a class described in the C++ Standard > Library as derived from another class is derived from that class > directly, or through other classes (with names reserved to the > implementation) that are derived from the specified base class." > > These quotes are from ISO/EIC 14882:2003. More modern ones > that I've looked at also include a 3rd context: > > "Implementations are permitted to provide addition predefined > variables with names that are reserve to the implementation > (5.10)." > > Otherwise having extra names is not restricted to using > "names reserved to the implementation", even in C++98 > and C++03 as far as I can tell. > > (I do not have a copy of the C++98 standard with me so I'm using > C++03's instead.) You are arguing that all names are reserved to the implementation, meaning no names are available to programmers and it is impossible to write C++ code. From owner-freebsd-toolchain@freebsd.org Mon Jul 31 19:55:33 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A06ADBC428 for ; Mon, 31 Jul 2017 19:55:33 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1036766257 for ; Mon, 31 Jul 2017 19:55:33 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 0C831DBC427; Mon, 31 Jul 2017 19:55:33 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C070DBC426 for ; Mon, 31 Jul 2017 19:55:33 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9CB6266256; Mon, 31 Jul 2017 19:55:32 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::8145:1768:6be6:c3c7] (unknown [IPv6:2001:470:7a58:0:8145:1768:6be6:c3c7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 8ABB12D48D; Mon, 31 Jul 2017 21:55:29 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_E246A37B-9E06-48A3-B1CE-2995E96A6D26"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build Date: Mon, 31 Jul 2017 21:55:20 +0200 In-Reply-To: <20170729015914.184c2660@kalimero.tijl.coosemans.org> Cc: toolchain@FreeBSD.org To: Tijl Coosemans References: <201707272142.v6RLg1G4099900@beefy12.nyi.freebsd.org> <20170728135510.2c6de57f@kalimero.tijl.coosemans.org> <20170729015914.184c2660@kalimero.tijl.coosemans.org> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 19:55:33 -0000 --Apple-Mail=_E246A37B-9E06-48A3-B1CE-2995E96A6D26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 29 Jul 2017, at 01:59, Tijl Coosemans wrote: >=20 > On Fri, 28 Jul 2017 19:54:04 +0200 Dimitry Andric = wrote: >> On 28 Jul 2017, at 13:55, Tijl Coosemans wrote: >>>=20 >>> On Thu, 27 Jul 2017 21:42:01 +0000 pkg-fallout@FreeBSD.org wrote: >> ... >>>> In file included from squirrel/squirrel/sqvm.cc:5: >>>> In file included from /usr/include/c++/v1/math.h:310: >>>> /usr/include/c++/v1/limits:149:85: error: expected expression >>>> _LIBCPP_INLINE_VISIBILITY static _LIBCPP_CONSTEXPR type max() = _NOEXCEPT {return type();} >>>> = ^ >>>> squirrel/squirrel/sqobject.h:131:24: note: expanded from macro = 'type' >>>> #define type(obj) ((obj)._type) >>>> ^ >>>=20 >>> Simutrans code defines 'type' as a macro. Shouldn't libc++ headers = use >>> _type or __type or something? >>=20 >> No, the member name 'type' is used in many classes in the C++ = standard >> library, for example all the traits in . Programs = should >> not attempt to redefine this, at least not as a macro. >>=20 >> Note that this also doesn't work with libstdc++, e.g.: >>=20 >> $ cat boom.cpp >> #define type "nope, this will not work" >> #include >>=20 >> and then: >>=20 >> $ g++ -c boom.cpp >> boom.cpp:1:14: error: expected unqualified-id before string constant >> #define type "nope, this will not work" >> ^ >> boom.cpp:1:14: error: expected class-name before string constant >> #define type "nope, this will not work" >> ^ >> boom.cpp:1:14: error: expected '{' before string constant >> boom.cpp:1:14: error: expected class-name before string constant >> #define type "nope, this will not work" >> ^ >> boom.cpp:1:14: error: expected '{' before string constant >> boom.cpp:1:14: error: expected class-name before string constant >> #define type "nope, this will not work" >> ^ >> boom.cpp:1:14: error: expected '{' before string constant >> boom.cpp:1:14: error: expected class-name before string constant >> #define type "nope, this will not work" >> ^ >> boom.cpp:1:14: error: expected '{' before string constant >> boom.cpp:1:14: error: expected unqualified-id before string constant >> #define type "nope, this will not work" >> ^ >> In file included from boom.cpp:3:0: >> /usr/local/lib/gcc6/include/c++/type_traits:212:60: error: template = argument 1 is invalid >> : public __is_void_helper::type>::type >> ^ >> /usr/local/lib/gcc6/include/c++/type_traits:212:61: error: expected = '{' before '::' token >> : public __is_void_helper::type>::type >> ^~ >> [...and lots more errors like this...] >=20 > The code does not include or any of that C++11 stuff. = It > includes . This works with libstdc++ because it doesn't have > , but it would also work when was included, because > libstdc++ uses __type everywhere (and __enable_if and __is_arithmetic, > etc. where libc++ headers use enable_if and is_arithmetic). The > libstdc++ way makes more sense. You cannot expect C++98 code to know > about reserved identifiers in C++11 or C++11 code to know about = reserved > identifiers in later standards. The usage of "type" as a name has been in libc++ since it was first imported upstream about 7 years ago, and the failure you showed is the first instance of such a name clash I have ever heard of. Therefore, I don't think it is too much trouble to change one older program to use a slightly different define. -Dimitry --Apple-Mail=_E246A37B-9E06-48A3-B1CE-2995E96A6D26 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.1 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWX+LKAAKCRCwXqMKLiCW ozWxAJ9LouTnQs4p1zxIktKYmaD6dC77rQCgo/QfsZgDRkRNkj+Zs8C2ruWvyJc= =+k5K -----END PGP SIGNATURE----- --Apple-Mail=_E246A37B-9E06-48A3-B1CE-2995E96A6D26-- From owner-freebsd-toolchain@freebsd.org Mon Jul 31 20:32:00 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7943CDBD10C for ; Mon, 31 Jul 2017 20:32:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 599956776D for ; Mon, 31 Jul 2017 20:32:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: by mailman.ysv.freebsd.org (Postfix) id 54DEDDBD10B; Mon, 31 Jul 2017 20:32:00 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4FCB4DBD10A for ; Mon, 31 Jul 2017 20:32:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-86.reflexion.net [208.70.210.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB4376776B for ; Mon, 31 Jul 2017 20:31:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30240 invoked from network); 31 Jul 2017 20:31:58 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 31 Jul 2017 20:31:58 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Mon, 31 Jul 2017 16:31:58 -0400 (EDT) Received: (qmail 23591 invoked from network); 31 Jul 2017 20:31:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 31 Jul 2017 20:31:57 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id E1BCEEC8029; Mon, 31 Jul 2017 13:31:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build From: Mark Millard In-Reply-To: <20170731214251.0a5de99b@kalimero.tijl.coosemans.org> Date: Mon, 31 Jul 2017 13:31:56 -0700 Cc: toolchain@FreeBSD.org, Dimitry Andric Content-Transfer-Encoding: quoted-printable Message-Id: <2426E5EB-518A-4B5B-8866-AD11D1AB95A3@dsl-only.net> References: <201707272142.v6RLg1G4099900@beefy12.nyi.freebsd.org> <20170728135510.2c6de57f@kalimero.tijl.coosemans.org> <20170729015914.184c2660@kalimero.tijl.coosemans.org> <20170729212706.33841c4c@kalimero.tijl.coosemans.org> <20170729230641.6cecd29d@kalimero.tijl.coosemans.org> <3E4B30BB-A9E5-480E-835D-DA6797FC230C@dsl-only.net> <20170731214251.0a5de99b@kalimero.tijl.coosemans.org> To: Tijl Coosemans X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 20:32:00 -0000 On 2017-Jul-31, at 12:42 PM, Tijl Coosemans wrote: > On Sat, 29 Jul 2017 22:16:46 -0700 Mark Millard = wrote: >> On 2017-Jul-29, at 3:24 PM, Mark Millard = wrote: >>> On 2017-Jul-29, at 2:06 PM, Tijl Coosemans = wrote: >>>> - Adding -std=3Dc++98 still fails to compile with the same errors. >>>>=20 >>>> - The compiler default is C++98: >>>> % c++ -x c++ -E -dM /dev/null | grep __cplusplus >>>> #define __cplusplus 199711L >>>>=20 >>>> - A quick look at the libc++ headers makes it immediately obvious = they >>>> expose and use C++11 features in C++98 mode. >>>>=20 >>>> And of course these were the very first things I checked before = writing >>>> my first email. =20 >>>=20 >>> Good to know. >>>=20 >>> Under C++03 (and before) the basic requirements for macro names >>> are different (and matching what you are attempting): 17.4.3.1.1 >>> Macro Names says: >>>=20 >>> "A translation unit that includes a header shall not contain any = macros >>> that define names declared or defined in that header." >>>=20 >>> This greatly narrows the range of potential conflicts. >>>=20 >>> (But my understanding is that the rule was changed in part >>> because headers implicitly including content from other >>> standard headers is classified as okay in the early standards >>> as well and so overall the early standards were not fully >>> consistent, given how macros are specified to operate.) >>>=20 >>> There is the issue that even for C++03 and before: >>>=20 >>> "Clauses 18 through 27 do not specify the representation of classes >>> . . . An implementation may define static or non-static class = members, >>> or both, as needed to implement the semantics of the member = functions >>> specified in clauses 18 through 27." >>>=20 >>> So far as I know (unlike C) C++ makes no requirements that imply >>> the "extra" names involved in such must not be valid names in >>> programs, although it allows for such. (Such as using __ prefixes >>> or _ prefixes. Or for the global namespace: _ >>> prefixes. These are reserved but not required to be used by the >>> implementation from what I can tell.) So as far as I know >>> such "pollution" is an implementation quality issue but not a >>> standards conformance issue so long as the naming does not >>> mess up programs' use of the required naming from the standard. >>>=20 >>> So what you report about "type" being in use as an identifier >>> in the library of itself looks greatly unfortunate to me but also >>> does not seem to be a violation of the C++98, C++03, or other >>> standard versions. (Drat.) >>>=20 >>> I've also not found anything indicating that extra declarations >>> and definitions (such as from C++11 for compiles targeting C++98 >>> or C++03) would be a violation of a standard, such as C++98 or >>> C++03. (At least for any addition that does not prevent programs' >>> use of required aspects of the library.) >>>=20 >>> This was a surprise to me. But so far I've not found anything to >>> point to for a "this is wrong by the rules of the standard" >>> submittal against libc++. That makes it less likely to change in >>> the future. =20 >>=20 >> I should have noted two contexts that do explicitly specify that >> "names reserved to the implementation" be used: >>=20 >> 17.4.4.7 Derived classes says both: >>=20 >> "It is unspecified whether a class in the C++ Standard Library it >> itself derived from other classes (with names reserved to the >> implementation)." >>=20 >> "It is unspecified whether a class described in the C++ Standard >> Library as derived from another class is derived from that class >> directly, or through other classes (with names reserved to the >> implementation) that are derived from the specified base class." >>=20 >> These quotes are from ISO/EIC 14882:2003. More modern ones >> that I've looked at also include a 3rd context: >>=20 >> "Implementations are permitted to provide addition predefined >> variables with names that are reserve to the implementation >> (5.10)." >>=20 >> Otherwise having extra names is not restricted to using >> "names reserved to the implementation", even in C++98 >> and C++03 as far as I can tell. >>=20 >> (I do not have a copy of the C++98 standard with me so I'm using >> C++03's instead.) >=20 > You are arguing that all names are reserved to the implementation, > meaning no names are available to programmers and it is impossible > to write C++ code. [If you find something in the standard that I've missed in my searches, please let me know.] [It is possible to write some C++ code without defining any macros. Macros are a bigger issue because they do not have/respect scope rules that limit where conflicts can occur.] No. Names local to classes (for example) that are from the standard library implementation do not constraint non-macro names used outside those scopes (for example). To my surprise those names are not required to be from the reserved naming space. But the standards do indicate that macro naming must avoid conflicts with such names, including those that are private to the implementation. I wrote for C++03 (and before), in part quoting the standard: > "A translation unit that includes a header shall not contain any = macros > that define names declared or defined in that header." >=20 > This greatly narrows the range of potential conflicts. >=20 > (But my understanding is that the rule was changed in part > because headers implicitly including content from other > standard headers is classified as okay in the early standards > as well and so overall the early standards were not fully > consistent, given how macros are specified to operate.) And for more modern contexts (quoting C++11's wording): > "A translation unit that include a standard library > header shall not #define or #undef names declared > in any standard library header." These make it a very good idea to avoid generic macro names that are fairly likely to be fairly common. May be here: #define sqobject_type(obj) ((obj)._type) This would be far less likely to end up with conflicts (until the standard gets something called a "sqobject" involved anyway). You certainly can submit a bugzilla report at: https://bugs.llvm.org/enter_bug.cgi?product=3Dlibc%2B%2B since FreeBSD gets libc++ from there (upstream). Complaints about quality issues that do not mean non-conformance are a valid thing to report so even if they agree with me on that point the submittal would be valid. llvm folks are just less likely to act on such issues. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon Jul 31 22:10:01 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 129B9DBEF2E for ; Mon, 31 Jul 2017 22:10:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E68786B29D for ; Mon, 31 Jul 2017 22:10:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: by mailman.ysv.freebsd.org (Postfix) id E1B7CDBEF2D; Mon, 31 Jul 2017 22:10:00 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1568DBEF2B for ; Mon, 31 Jul 2017 22:10:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-85.reflexion.net [208.70.210.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9E0E36B29C for ; Mon, 31 Jul 2017 22:09:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21828 invoked from network); 31 Jul 2017 22:09:53 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 31 Jul 2017 22:09:53 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Mon, 31 Jul 2017 18:09:53 -0400 (EDT) Received: (qmail 10218 invoked from network); 31 Jul 2017 22:09:52 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 31 Jul 2017 22:09:52 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 145DBEC867E; Mon, 31 Jul 2017 15:09:52 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build Date: Mon, 31 Jul 2017 15:09:51 -0700 References: <201707272142.v6RLg1G4099900@beefy12.nyi.freebsd.org> <20170728135510.2c6de57f@kalimero.tijl.coosemans.org> <20170729015914.184c2660@kalimero.tijl.coosemans.org> <20170729212706.33841c4c@kalimero.tijl.coosemans.org> <20170729230641.6cecd29d@kalimero.tijl.coosemans.org> <3E4B30BB-A9E5-480E-835D-DA6797FC230C@dsl-only.net> <20170731214251.0a5de99b@kalimero.tijl.coosemans.org> <2426E5EB-518A-4B5B-8866-AD11D1AB95A3@dsl-only.net> To: Tijl Coosemans , toolchain@FreeBSD.org In-Reply-To: <2426E5EB-518A-4B5B-8866-AD11D1AB95A3@dsl-only.net> Message-Id: <719173E8-3331-4A93-9A7E-8008AD0DFC32@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 22:10:01 -0000 [I quote C++03's material about standard headers including each other: what is allowed and what is required.] On 2017-Jul-31, at 1:31 PM, Mark Millard wrote: > On 2017-Jul-31, at 12:42 PM, Tijl Coosemans = wrote: >=20 >> On Sat, 29 Jul 2017 22:16:46 -0700 Mark Millard = wrote: >>> On 2017-Jul-29, at 3:24 PM, Mark Millard = wrote: >>>> On 2017-Jul-29, at 2:06 PM, Tijl Coosemans = wrote: >>>>> - Adding -std=3Dc++98 still fails to compile with the same errors. >>>>>=20 >>>>> - The compiler default is C++98: >>>>> % c++ -x c++ -E -dM /dev/null | grep __cplusplus >>>>> #define __cplusplus 199711L >>>>>=20 >>>>> - A quick look at the libc++ headers makes it immediately obvious = they >>>>> expose and use C++11 features in C++98 mode. >>>>>=20 >>>>> And of course these were the very first things I checked before = writing >>>>> my first email. =20 >>>>=20 >>>> Good to know. >>>>=20 >>>> Under C++03 (and before) the basic requirements for macro names >>>> are different (and matching what you are attempting): 17.4.3.1.1 >>>> Macro Names says: >>>>=20 >>>> "A translation unit that includes a header shall not contain any = macros >>>> that define names declared or defined in that header." >>>>=20 >>>> This greatly narrows the range of potential conflicts. >>>>=20 >>>> (But my understanding is that the rule was changed in part >>>> because headers implicitly including content from other >>>> standard headers is classified as okay in the early standards >>>> as well and so overall the early standards were not fully >>>> consistent, given how macros are specified to operate.) >>>>=20 >>>> There is the issue that even for C++03 and before: >>>>=20 >>>> "Clauses 18 through 27 do not specify the representation of classes >>>> . . . An implementation may define static or non-static class = members, >>>> or both, as needed to implement the semantics of the member = functions >>>> specified in clauses 18 through 27." >>>>=20 >>>> So far as I know (unlike C) C++ makes no requirements that imply >>>> the "extra" names involved in such must not be valid names in >>>> programs, although it allows for such. (Such as using __ prefixes >>>> or _ prefixes. Or for the global namespace: _ >>>> prefixes. These are reserved but not required to be used by the >>>> implementation from what I can tell.) So as far as I know >>>> such "pollution" is an implementation quality issue but not a >>>> standards conformance issue so long as the naming does not >>>> mess up programs' use of the required naming from the standard. >>>>=20 >>>> So what you report about "type" being in use as an identifier >>>> in the library of itself looks greatly unfortunate to me but also >>>> does not seem to be a violation of the C++98, C++03, or other >>>> standard versions. (Drat.) >>>>=20 >>>> I've also not found anything indicating that extra declarations >>>> and definitions (such as from C++11 for compiles targeting C++98 >>>> or C++03) would be a violation of a standard, such as C++98 or >>>> C++03. (At least for any addition that does not prevent programs' >>>> use of required aspects of the library.) >>>>=20 >>>> This was a surprise to me. But so far I've not found anything to >>>> point to for a "this is wrong by the rules of the standard" >>>> submittal against libc++. That makes it less likely to change in >>>> the future. =20 >>>=20 >>> I should have noted two contexts that do explicitly specify that >>> "names reserved to the implementation" be used: >>>=20 >>> 17.4.4.7 Derived classes says both: >>>=20 >>> "It is unspecified whether a class in the C++ Standard Library it >>> itself derived from other classes (with names reserved to the >>> implementation)." >>>=20 >>> "It is unspecified whether a class described in the C++ Standard >>> Library as derived from another class is derived from that class >>> directly, or through other classes (with names reserved to the >>> implementation) that are derived from the specified base class." >>>=20 >>> These quotes are from ISO/EIC 14882:2003. More modern ones >>> that I've looked at also include a 3rd context: >>>=20 >>> "Implementations are permitted to provide addition predefined >>> variables with names that are reserve to the implementation >>> (5.10)." >>>=20 >>> Otherwise having extra names is not restricted to using >>> "names reserved to the implementation", even in C++98 >>> and C++03 as far as I can tell. >>>=20 >>> (I do not have a copy of the C++98 standard with me so I'm using >>> C++03's instead.) >>=20 >> You are arguing that all names are reserved to the implementation, >> meaning no names are available to programmers and it is impossible >> to write C++ code. >=20 > [If you find something in the standard that I've missed in my > searches, please let me know.] >=20 > [It is possible to write some C++ code without defining any > macros. Macros are a bigger issue because they do not > have/respect scope rules that limit where conflicts can > occur.] >=20 > No. Names local to classes (for example) that are from the > standard library implementation do not constraint non-macro > names used outside those scopes (for example). To my surprise > those names are not required to be from the reserved naming > space. >=20 > But the standards do indicate that macro naming must avoid > conflicts with such names, including those that are private > to the implementation. >=20 > I wrote for C++03 (and before), in part quoting the standard: >=20 >> "A translation unit that includes a header shall not contain any = macros >> that define names declared or defined in that header." >>=20 >> This greatly narrows the range of potential conflicts. >>=20 >> (But my understanding is that the rule was changed in part >> because headers implicitly including content from other >> standard headers is classified as okay in the early standards >> as well and so overall the early standards were not fully >> consistent, given how macros are specified to operate.) >=20 >=20 > And for more modern contexts (quoting C++11's wording): >=20 >> "A translation unit that include a standard library >> header shall not #define or #undef names declared >> in any standard library header." >=20 > These make it a very good idea to avoid generic macro > names that are fairly likely to be fairly common. May be > here: >=20 > #define sqobject_type(obj) ((obj)._type) >=20 > This would be far less likely to end up with conflicts > (until the standard gets something called a "sqobject" > involved anyway). >=20 >=20 > You certainly can submit a bugzilla report at: >=20 > https://bugs.llvm.org/enter_bug.cgi?product=3Dlibc%2B%2B >=20 > since FreeBSD gets libc++ from there (upstream). Complaints > about quality issues that do not mean non-conformance are > a valid thing to report so even if they agree with me on > that point the submittal would be valid. llvm folks are just > less likely to act on such issues. Here is the core of what C++03 has to say about standard headers including each other. I'd not managed to quote it before. (I've been trying to avoid a "just my say so" status in what I've written.) ISO/IEC 14882:2003's 17.4 is "Library-wide requirements". 17.4.4.1 "Headers" (so: standard headers) says in part: "A C++ header may include other C++ headers." That text has a foot note 170 that says: "C++ headers must include a C++ header that contains any needed definition (3.2)." There is also a special rule for the .h form of C headers: "Header inclusion is limited as follows: -- The C headers ( .h form, described in Annex D, D.5) shall include only their corresponding C++ header, as described above (17.4.1.2)." Of course the C++ header (non-.h form) then can do more includes. Side note: It had been a long time since I'd been through this stuff --and I'd not been tracking recent C++ standard versions in much detail. It has been good for me to go through this subject area. It also has been good to see that some of the mis-matched material in earlier versions has been updated to cover things better. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Wed Aug 2 17:38:52 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43422DAE767 for ; Wed, 2 Aug 2017 17:38:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3173D6E611 for ; Wed, 2 Aug 2017 17:38:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v72HcpXk059695 for ; Wed, 2 Aug 2017 17:38:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 220590] math/fftw3: fails to build on armv6 (729 ports skipped) Date: Wed, 02 Aug 2017 17:38:51 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-patch, regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jhale@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: see_also Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 17:38:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220590 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=3D2= 211 | |82 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Aug 2 17:38:52 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6518DDAE769 for ; Wed, 2 Aug 2017 17:38:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 530316E612 for ; Wed, 2 Aug 2017 17:38:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v72HcpXm059695 for ; Wed, 2 Aug 2017 17:38:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 220591] graphics/graphviz: fails to build on armv6 (451 ports skipped) Date: Wed, 02 Aug 2017 17:38:51 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: dinoex@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: see_also Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 17:38:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220591 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=3D2= 211 | |82 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Aug 3 05:05:01 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CBDDCDCA2D4 for ; Thu, 3 Aug 2017 05:05:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B8A6666CB5 for ; Thu, 3 Aug 2017 05:05:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v73551ZC054033 for ; Thu, 3 Aug 2017 05:05:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 220590] math/fftw3: fails to build on armv6 (729 ports skipped) Date: Thu, 03 Aug 2017 05:05:01 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-patch, regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jhale@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ merge-quarterly+ X-Bugzilla-Changed-Fields: flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 05:05:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220590 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |merge-quarterly+ --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Aug 3 15:14:06 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66089DC2A8F for ; Thu, 3 Aug 2017 15:14:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 543F181DC6 for ; Thu, 3 Aug 2017 15:14:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v73FE5VU006339 for ; Thu, 3 Aug 2017 15:14:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 219484] cad/openvsp: Fails to build with lang/gcc6 or later on 10.3 (< 11.0) Date: Thu, 03 Aug 2017 15:14:05 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: rakuco@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ merge-quarterly- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 15:14:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219484 --- Comment #24 from commit-hook@freebsd.org --- A commit references this bug: Author: feld Date: Thu Aug 3 15:13:32 UTC 2017 New revision: 447224 URL: https://svnweb.freebsd.org/changeset/ports/447224 Log: MFH: r446855 Explicitly build with -std=3Dgnu++11. This fixes the build with GCC 6, which switched its default from -std=3Dg= nu++98 to -std=3Dgnu++14. With this switch, it added a `operator delete(void*, size_t)' overload and uses it for all delete calls. This does not play well with dependencies built with other compilers (such as base clang), which use t= he old operator delete overload and cause linking errors. PR: 219484 Submitted by: fernando.apesteguia@gmail.com (maintainer) Approved by: ports-secteam (with hat) Changes: _U branches/2017Q3/ branches/2017Q3/cad/openvsp/Makefile --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Aug 5 05:33:49 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 547C9DBED88 for ; Sat, 5 Aug 2017 05:33:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4224566400 for ; Sat, 5 Aug 2017 05:33:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v755XmrX001717 for ; Sat, 5 Aug 2017 05:33:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 219484] cad/openvsp: Fails to build with lang/gcc6 or later on 10.3 (< 11.0) Date: Sat, 05 Aug 2017 05:33:48 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: rakuco@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ merge-quarterly+ X-Bugzilla-Changed-Fields: flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 05:33:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219484 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|merge-quarterly- |merge-quarterly+ --=20 You are receiving this mail because: You are on the CC list for the bug.=