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
