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