Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build

[Mark Millard]

[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:
> 
>> 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.
> 
> [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 

Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build

[Mark Millard]

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=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.

[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 

Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build

[Dimitry Andric]

On 29 Jul 2017, at 01:59, 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 + pkg-fall...@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.

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



signature.asc
Description: Message signed with OpenPGP

Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build

[Tijl Coosemans]

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.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build

[Mark Millard]

[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:
> 
>> On Sat, 29 Jul 2017 12:43:59 -0700 Mark Millard  
>> wrote:
>>> On 2017-Jul-29, at 12:27 PM, Tijl Coosemans  wrote:
> . . .
 
 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:
> 
> Very true that I should not have bothered to try to
> write something in all 3 places.
> 
> Your sequence gives additional information in each
> of your 3 and so does not have my mistake.
> 
>> - 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 

Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build

[Mark Millard]

On 2017-Jul-29, at 2:06 PM, Tijl Coosemans  wrote:

> On Sat, 29 Jul 2017 12:43:59 -0700 Mark Millard  
> wrote:
>> On 2017-Jul-29, at 12:27 PM, Tijl Coosemans  wrote:
 . . .
>>> 
>>> 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:

Very true that I should not have bothered to try to
write something in all 3 places.

Your sequence gives additional information in each
of your 3 and so does not have my mistake.

> - 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 

Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build

[Tijl Coosemans]

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 + 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.

Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build

[Mark Millard]

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 + 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  

Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build

[Tijl Coosemans]

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 + pkg-fall...@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.  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?

> For targeting -std=c++11 or later in compiles
> __enable_if and __is_arithemtic and __type

Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build

[Mark Millard]

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 + pkg-fall...@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;
. . .
};

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.

As I remember the standard  makes few or no
guarantees about avoiding implicitly getting
more of the library header definitions than
the #includes explicitly reference in the
using code.

Your wording fits better for identifiers
that have no such mandated existence in
any part of the library for the c++??
being targeted in the compile. (It is
not the source code's intended target
that directly 

Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build

[Tijl Coosemans]

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 + pkg-fall...@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.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build

[Dimitry Andric]

On 28 Jul 2017, at 13:55, Tijl Coosemans  wrote:
> 
> On Thu, 27 Jul 2017 21:42:01 + pkg-fall...@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...]

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build

[Tijl Coosemans]

On Thu, 27 Jul 2017 21:42:01 + pkg-fall...@freebsd.org wrote:
> You are receiving this mail as a port that you maintain
> is failing to build on the FreeBSD package build server.
> Please investigate the failure and submit a PR to fix
> build.
> 
> Maintainer: t...@freebsd.org
> Last committer: t...@freebsd.org
> Ident:  $FreeBSD: head/games/simutrans/Makefile 441004 2017-05-16 
> 15:28:53Z tijl $
> Log URL:
> http://beefy12.nyi.freebsd.org/data/head-amd64-default/p446708_s321589/logs/simutrans-120.2.2.log
> Build URL:  
> http://beefy12.nyi.freebsd.org/build.html?mastername=head-amd64-default=p446708_s321589
> Log:
> 
> >> Building games/simutrans  
> build started at Thu Jul 27 21:35:40 UTC 2017
> port directory: /usr/ports/games/simutrans
> building for: FreeBSD head-amd64-default-job-06 12.0-CURRENT FreeBSD 
> 12.0-CURRENT 1200039 amd64
> maintained by: t...@freebsd.org
> Makefile ident:  $FreeBSD: head/games/simutrans/Makefile 441004 
> 2017-05-16 15:28:53Z tijl $
> Poudriere version: 3.1.19-51-g177d9e6d
> Host OSVERSION: 1200033
> Jail OSVERSION: 1200039
> Job Id: 06
> 
> 
> 
> 
> !!! Jail is newer than host. (Jail: 1200039, Host: 1200033) !!!
> !!! This is not supported. !!!
> !!! Host kernel must be same or newer than jail. !!!
> !!! Expect build failures. !!!
> 
> 
> 
> ---Begin Environment---
> SHELL=/bin/csh
> OSVERSION=1200039
> UNAME_v=FreeBSD 12.0-CURRENT 1200039
> UNAME_r=12.0-CURRENT
> BLOCKSIZE=K
> MAIL=/var/mail/root
> STATUS=1
> SAVED_TERM=
> MASTERMNT=/usr/local/poudriere/data/.m/head-amd64-default/ref
> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
> POUDRIERE_BUILD_TYPE=bulk
> PKGNAME=simutrans-120.2.2
> OLDPWD=/
> PWD=/usr/local/poudriere/data/.m/head-amd64-default/ref/.p/pool
> MASTERNAME=head-amd64-default
> SCRIPTPREFIX=/usr/local/share/poudriere
> USER=root
> HOME=/root
> POUDRIERE_VERSION=3.1.19-51-g177d9e6d
> SCRIPTPATH=/usr/local/share/poudriere/bulk.sh
> LIBEXECPREFIX=/usr/local/libexec/poudriere
> LOCALBASE=/usr/local
> POUDRIEREPATH=/usr/local/bin/poudriere
> ---End Environment---
> 
> ---Begin Poudriere Port Flags/Env---
> PORT_FLAGS=
> PKGENV=
> ---End Poudriere Port Flags/Env---
> 
> ---Begin OPTIONS List---
> ===> The following configuration options are available for simutrans-120.2.2: 
>  
>  DOCS=on: Build and/or install documentation
> > Options available for the multi PAK: you have to choose at least one of 
> them  
>  PAK64=on: Default graphics
>  PAK128=off: High resolution graphics
> ===> Use 'make config' to modify these settings  
> ---End OPTIONS List---
> 
> --CONFIGURE_ARGS--
> 
> --End CONFIGURE_ARGS--
> 
> --CONFIGURE_ENV--
> SDL_CONFIG=/usr/local/bin/sdl-config MAKE=gmake 
> XDG_DATA_HOME=/wrkdirs/usr/ports/games/simutrans/work  
> XDG_CONFIG_HOME=/wrkdirs/usr/ports/games/simutrans/work  
> HOME=/wrkdirs/usr/ports/games/simutrans/work TMPDIR="/tmp" SHELL=/bin/sh 
> CONFIG_SHELL=/bin/sh
> --End CONFIGURE_ENV--
> 
> --MAKE_ENV--
> SDL_CONFIG=/usr/local/bin/sdl-config 
> XDG_DATA_HOME=/wrkdirs/usr/ports/games/simutrans/work  
> XDG_CONFIG_HOME=/wrkdirs/usr/ports/games/simutrans/work  
> HOME=/wrkdirs/usr/ports/games/simutrans/work TMPDIR="/tmp" NO_PIE=yes 
> MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh NO_LINT=YES 
> PREFIX=/usr/local  LOCALBASE=/usr/local  LIBDIR="/usr/lib"  CC="cc" 
> CFLAGS="-O2 -pipe  -fstack-protector -fno-strict-aliasing"  CPP="cpp" 
> CPPFLAGS=""  LDFLAGS=" -fstack-protector" LIBS=""  CXX="c++" CXXFLAGS="-O2 
> -pipe -fstack-protector -fno-strict-aliasing "  MANPREFIX="/usr/local" 
> BSD_INSTALL_PROGRAM="install  -s -m 555"  BSD_INSTALL_LIB="install  -s -m 
> 0644"  BSD_INSTALL_SCRIPT="install  -m 555"  BSD_INSTALL_DATA="install  -m 
> 0644"  BSD_INSTALL_MAN="install  -m 444"
> --End MAKE_ENV--
> 
> --PLIST_SUB--
> OSREL=12.0
> PREFIX=%D
> LOCALBASE=/usr/local
> RESETPREFIX=/usr/local
> PORTDOCS=""
> PORTEXAMPLES=""
> LIB32DIR=lib
> DOCSDIR="share/doc/simutrans"
> EXAMPLESDIR="share/examples/simutrans"
> DATADIR="share/simutrans"
> WWWDIR="www/simutrans"
> ETCDIR="etc/simutrans"
> --End PLIST_SUB--
> 
> --SUB_LIST--
> PREFIX=/usr/local
> LOCALBASE=/usr/local
> DATADIR=/usr/local/share/simutrans
> DOCSDIR=/usr/local/share/doc/simutrans
> EXAMPLESDIR=/usr/local/share/examples/simutrans
> WWWDIR=/usr/local/www/simutrans
> ETCDIR=/usr/local/etc/simutrans
> --End SUB_LIST--
> 
> ---Begin make.conf---
> USE_PACKAGE_DEPENDS=yes
> BATCH=yes
> WRKDIRPREFIX=/wrkdirs
> PORTSDIR=/usr/ports
> PACKAGES=/packages
> DISTDIR=/distfiles
> PACKAGE_BUILDING=yes
>  /usr/local/etc/poudriere.d/make.conf 
> # XXX: We really need this but cannot use it while 'make checksum' does not
> # try the next mirror on checksum failure.  It currently retries the same
> # failed mirror and then fails rather then trying another.  It *does*
> # try the next if the size is mismatched though.
> #MASTER_SITE_FREEBSD=yes
> # Build ALLOW_MAKE_JOBS_PACKAGES with 2 jobs
>