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"

[Bug 220590] math/fftw3: fails to build on armv6 (729 ports skipped)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220590

--- Comment #11 from commit-h...@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=CC   --mode=link /nxb-bin/usr/bin/cc -D_THREAD_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-bench.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 invocation)
  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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 220590] math/fftw3: fails to build on armv6 (729 ports skipped)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220590

Jason E. Hale  changed:

   What|Removed |Added

 Status|In Progress |Closed
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 220590] math/fftw3: fails to build on armv6 (729 ports skipped)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220590

--- Comment #10 from commit-h...@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=CC   --mode=link /nxb-bin/usr/bin/cc -D_THREAD_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-bench.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 invocation)
  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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: libstdc++ build failures on MIPS, PowerPC, Sparc

[Mark Millard]

[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.]
> 
> 
> Ravi Pokala rpokala at mac.com wrote on
> Sun Jul 23 19:44:57 UTC 2017 :
> 
>> I did a tinderbox build of -HEAD as of r321376; there were failures like 
>> this (paths shortened):
>> 
>>   c++ -isystem ${OUTDIR}/tmp/usr/include/c++/v1 -std=c++11  -nostdinc++ 
>> -isystem ${OUTDIR}/tmp/usr/include -L${OUTDIR}/tmp/usr/lib 
>> -B${OUTDIR}/tmp/usr/lib --sysroot=${OUTDIR}/tmp -B${OUTDIR}/tmp/usr/bin  -O 
>> -pipe -G0 -EB -mabi=32 -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=RepeatabilityConsideredGood   -fno-implicit-templates 
>> -ffunction-sections -fdata-sections -Wno-deprecated   -c 
>> ${SRCDIR}/contrib/libstdc++/src/bitmap_allocator.cc -o bitmap_allocator.o
>> 
>>   cc1plus: error: unrecognized command line option "-std=c++11"
>>   *** [bitmap_allocator.o] Error code 1
>> 
>> on multiple worlds:
>> 
>>   [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
>> 
>> 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.

===
Mark Millard
markmi at dsl-only.net

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