From owner-freebsd-toolchain@freebsd.org Sat Jul 29 21:07:59 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 04082DCB21B for ; Sat, 29 Jul 2017 21:07:59 +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 B826B7C4FD for ; Sat, 29 Jul 2017 21:07:58 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id B4513DCB21A; Sat, 29 Jul 2017 21:07:58 +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 B22A1DCB219 for ; Sat, 29 Jul 2017 21:07:58 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay102.isp.belgacom.be (mailrelay102.isp.belgacom.be [195.238.20.129]) (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 C56ED7C4EB; Sat, 29 Jul 2017 21:07:57 +0000 (UTC) (envelope-from tijl@freebsd.org) X-Belgacom-Dynamic: yes IronPort-PHdr: =?us-ascii?q?9a23=3A7yB8Ix12DWsvQc6nsmDT+DRfVm0co7zxezQtwd8Z?= =?us-ascii?q?seIeL/ad9pjvdHbS+e9qxAeQG96Ku7Qc06L/iOPJYSQ4+5GPsXQPItRndiQuro?= =?us-ascii?q?EopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZv?= =?us-ascii?q?JuTyB4Xek9m72/q89pDXYAhEniaxba9vJxiqsAvdsdUbj5F/Iagr0BvJpXVIe+?= =?us-ascii?q?VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PGAv5c3krgfM?= =?us-ascii?q?QA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7Vq4/Vyi84Kh3SR/okC?= =?us-ascii?q?YHOCA/8GHLkcx7kaZXrAu8qxBj34LYZYeYP+d8cKzAZ9MXXWRPUMZPWSJcAY2z?= =?us-ascii?q?bYUPAOUdMuhXtIT9u1kDoQeiCQWwGO/j1DlFjWL2060g1OQhFBnL0hIhH9IMtH?= =?us-ascii?q?Tfscv4NKAVUeCu0qbIyC/Mb/VN2Tzg74XIbhEhofOIXb9rccTR01cgGB3Yg1uN?= =?us-ascii?q?p4LpJTSV1v4Cs2WC6edrSOyhi2kiqw5rozivwN8hiofTho0L1F/L7j55z5svKd?= =?us-ascii?q?2/Uk57bsaoH4ZLtyGeLod2RcUiQ2VouSogzL0Jp4K7cS4Xw5ok3x7Sc/+Kf5WS?= =?us-ascii?q?7h79W+ucIS10iG9ndb+7nRq+7EqtxvH6W8KpylhFtDBFncPJtn0V0hzT7dWIRe?= =?us-ascii?q?Vl80e63DaPyxjT6uZZIUAojabbK4Auwro3lpcLskTMBCv2mETzjKCIbEUk/fKk?= =?us-ascii?q?6/jmYrXkop+QLZN7igb5MqQ1hMO/BP43Mg4VX2SB/uS8zrLj8VX4QLVMkPI2jr?= =?us-ascii?q?HUvZPHKcgBuKK0DA9Y3pw+5xu9CzqqyskUkHsbIF5dfRKIlYnpO1XAIPDiCve/?= =?us-ascii?q?hkyhkCtqx/DEOr3sGZvNLmLdn7j/Zrl98FNTxBA0zdBF6JJYEqsBL+7rWk/tqN?= =?us-ascii?q?zYCQc0MxCzw+bgDNVyyoMeVniOAq+fK67Sv0WI6fwxLOaXf48apSzxK/8/5/7h?= =?us-ascii?q?lXU5g0MSfbG13ZsLb3C1BulpI0ScYXf3jNcBC3kFsRQlQ+zxlVKOSzlTZ2y9X/?= =?us-ascii?q?F02jZuLYu8Ds/mR4SpiaaNlHO+F4dVY2FuBkuIVHDuc5TCXfoQPnG8OMhkxwAF?= =?us-ascii?q?V7zpYIgmzhyrvQnhg+57L+jQ0gMCuJ/J7/Qz4Pfcw0JhvQdoBtiQhjneB1p/mX?= =?us-ascii?q?kFEnpvhPhy?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DOBQCW93xZ/6qz9VFcGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBFAEBAQEBAQEBAQEBBwEBAQEBgy9EEBBtJ48AjwYBgWstAZVdDoI?= =?us-ascii?q?EJIFYg0sCg3NCFgEBAQEBAQEBAQEBaihCDoFjJAGCQQEFOhwjEAsYCSUPKh4GE?= =?us-ascii?q?4ozsw6LPAEBAQEBAQEDAQEBAQEjgyiIITSDAYFAARIBhhMFiWGHCoFijSKHT4N?= =?us-ascii?q?MBYh6fIF0j1qVciYCL38LUzEIhV8cGYFQPjaDFYRpgjEBAQE?= X-IPAS-Result: =?us-ascii?q?A2DOBQCW93xZ/6qz9VFcGQEBAQEBAQEBAQEBBwEBAQEBFAE?= =?us-ascii?q?BAQEBAQEBAQEBBwEBAQEBgy9EEBBtJ48AjwYBgWstAZVdDoIEJIFYg0sCg3NCF?= =?us-ascii?q?gEBAQEBAQEBAQEBaihCDoFjJAGCQQEFOhwjEAsYCSUPKh4GE4ozsw6LPAEBAQE?= =?us-ascii?q?BAQEDAQEBAQEjgyiIITSDAYFAARIBhhMFiWGHCoFijSKHT4NMBYh6fIF0j1qVc?= =?us-ascii?q?iYCL38LUzEIhV8cGYFQPjaDFYRpgjEBAQE?= 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; 29 Jul 2017 23:06:44 +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 v6TL6gek004891; Sat, 29 Jul 2017 23:06:43 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Sat, 29 Jul 2017 23:06:41 +0200 From: Tijl Coosemans To: Mark Millard Cc: Dimitry Andric , toolchain@FreeBSD.org Subject: Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build Message-ID: <20170729230641.6cecd29d@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> 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: Sat, 29 Jul 2017 21:07:59 -0000 On Sat, 29 Jul 2017 12:43:59 -0700 Mark Millard wrote: > On 2017-Jul-29, at 12:27 PM, Tijl Coosemans wrote: >> On Sat, 29 Jul 2017 00:34:39 -0700 Mark Millard wrote: >>> On 2017-Jul-28, at 4:59 PM, Tijl Coosemans wrote: >>>> On Fri, 28 Jul 2017 19:54:04 +0200 Dimitry Andric wrote: >>>>> On 28 Jul 2017, at 13:55, Tijl Coosemans wrote: >>>>>> >>>>>> On Thu, 27 Jul 2017 21:42:01 +0000 pkg-fallout at 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) >>>>>>> ^ >>>>>> >>>>>> Simutrans code defines 'type' as a macro. Shouldn't libc++ headers use >>>>>> _type or __type or something? >>>>> >>>>> 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. >>>>> >>>>> Note that this also doesn't work with libstdc++, e.g.: >>>>> >>>>> $ cat boom.cpp >>>>> #define type "nope, this will not work" >>>>> #include >>>>> >>>>> and then: >>>>> >>>>> $ 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...] >>>> >>>> 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. >>> >>> I'll first note that Annex D D.5 C standard library >>> headers says: >>> >>> "the C++ standard library provides the 25 C headers, >>> as shown in table 154" >>> >>> and table 154 lists: . That is relevant >>> for the below. >>> >>> ISO/IEC 14882:2011(E) 17.6.4.3.1 Macro Names >>> says: >>> >>> "A translation unit that include a standard library >>> header shall not #define or #undef names declared >>> in any standard library header." >>> >>> I'll note that the standard has sections with titles >>> like "Type names", "Class names", "Nested type names", >>> "Names of template specializations", and "Predefined >>> macro names". My understanding is that the earlier >>> quote spans avoiding matching all such names. >>> >>> >>> >>> ISO/IEC 14882:2011(E) mandates such things as: >>> >>> template struct is_arithmetic; >>> . . . >>> template struct enable_if; >>> . . . >>> template typedef integral_constant { >>> . . . >>> typedef integral_constant type; >>> . . . >>> }; >> >> But none of this should be exposed to C++98 code. > > 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. > > 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: > > 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=8163 -I/usr/local/include/SDL -I/usr/local/include -D_REENTRANT -D_THREAD_SAFE -DCOLOUR_DEPTH=16 -c -MMD -o build/default/squirrel/squirrel/sqvm.o squirrel/squirrel/sqvm.cc > > 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. > >> 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? > > Unless you tell the compiler to use C++98 rules you get the > rules of whatever version it targets by default. > >>> For targeting -std=c++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= but depending on a >>> default that happens to end up with c++11 or >>> later as the version to target. >> >> Of course things like __enable_if are for internal use only. In C++11 >> mode enable_if needs to be made available. > > And if the compiler default version target was > C++11 or later then what it did was what it should > have done. Since you've written three times the same thing here let me reply with three times the same thing: - 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.