Stuart Henderson schrieb am 19.05.2014 23:23:

> On 2014/05/19 18:07, Nils R wrote:
>> >> # some source files contain a BOM which gcc 4.2.1 can't handle
>> > 
>> > If that's the only reason for using a gplv3 GCC, can these files just
>> > be patched instead? Alternatively, how does clang handle them?
>> > 
>> 
>> clang fails to build because of some problems with gtest, but i had no time 
>> to look into it.  Might not be a big issue though.  Should i conclude from
>> this that clang is favoured over a gpl3 licensed gcc?  If so, is there a 
>> reason to favor non-gpl3 compilers for ports?
> 
> My preferences in order (*if* things work properly with that compiler) :-
> 
> 1. default compiler from the base os
> 2. ports clang
> 3. ports gcc
> 
> If it's just a small fix to be able to use 1) then do that, don't stack
> things in a bulk build behind a (slow) build of an additional C compiler
> if that isn't needed.
> 
> 1) and 2) currently use libstdc++ from base, avoiding conflicts.
> 

Ok, makes sense.  Thank you for the explanation.


> Some specific points about this port; please add this:
> 
>       MAKE_FLAGS= Q= CXX="${CXX}" CC="${CC}"
> 
> Q= disables hiding command lines in upstream's Makefile, the others
> honour user choices of compiler.
> 

done


> As for the BOM it can just be stripped
> 
> # strip BOM, gcc 4.2.1 doesn't understand it
> post-extract:
>       perl -pi -e 's,\xef\xbb\xbf,,' ${WRKSRC}/Build/Utils/_*Text.cc
> 

Thanks, this won't be fixed upstream because Visual Studio adds a BOM every
time the file is saved, but this line is a quick and easy fix.


> it runs into various gtest-related problems e.g.
> 
> _build/lib-gtest/src/gtest-internal-inl.h:86: error: expected constructor,
> destructor, or type conversion before 'extern'
> _build/lib-gtest/src/gtest-internal-inl.h:109: error: expected constructor,
> destructor, or type conversion before 'extern'
> _build/lib-gtest/src/gtest-internal-inl.h:112: error: 'GTEST_API_' does not
> name a type
> [...]
> 
> do we need the tests anyway though? adding WITH_UNITTESTS=0 to MAKE_FLAGS
> skips them and then it builds with base gcc.
> 

We don't need the tests, but there still is this weird thing i still don't get:
when i compile the source code directly (with a new gcc/g++), there are no gtest
problems, and all tests pass (without the stdc++ confusion).  However, when 
compiling it with the ports Makefile, these problems show up.  I'll try to
find the reason for this tomorrow.

Nils

Reply via email to