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