Trying to build tag v2.8.0 as external project getting some compiler standard error

[BotelhoVinicius]

Hello,
I'm trying to build the tag v2.8.0 due some target system restrictions and i'm using external_project to incorporate the cpprest on my build.
The problem is:
When i'm trying to build, i get some errors in C++11 standards, like:

In file included from /RamalMaisSync/.build/third_party/src/cpprestsdk/Release/src/pch/stdafx.h:119:0,
from /RamalMaisSync/.build/third_party/src/cpprestsdk/Release/src/http/client/http_client_msg.cpp:25:
/RamalMaisSync/.build/third_party/src/cpprestsdk/Release/include/cpprest/json.h:316:76: error: '<::' cannot begin a template-argument list [-fpermissive]
/RamalMaisSync/.build/third_party/src/cpprestsdk/Release/include/cpprest/json.h:316:76: note: '<:' is an alternate spelling for '['. Insert whitespace between '<' and '::'
/RamalMaisSync/.build/third_party/src/cpprestsdk/Release/include/cpprest/json.h:316:76: note: (if you use '-fpermissive' G++ will accept your code)
In file included from /RamalMaisSync/.build/third_party/src/cpprestsdk/Release/src/pch/stdafx.h:127:0,
from /RamalMaisSync/.build/third_party/src/cpprestsdk/Release/src/http/client/http_client_msg.cpp:25:
/RamalMaisSync/.build/third_party/src/cpprestsdk/Release/include/cpprest/details/web_utilities.h:48:24: error: '<::' cannot begin a template-argument list [-fpermissive]
/RamalMaisSync/.build/third_party/src/cpprestsdk/Release/include/cpprest/details/web_utilities.h:48:24: note: '<:' is an alternate spelling for '['. Insert whitespace between '<' and '::'
In file included from /RamalMaisSync/.build/third_party/src/cpprestsdk/Release/src/pch/stdafx.h:132:0,
from /RamalMaisSync/.build/third_party/src/cpprestsdk/Release/src/http/client/http_client_msg.cpp:25:
/RamalMaisSync/.build/third_party/src/cpprestsdk/Release/include/cpprest/http_client.h:732:20: error: '<::' cannot begin a template-argument list [-fpermissive]
/RamalMaisSync/.build/third_party/src/cpprestsdk/Release/include/cpprest/http_client.h:732:20: note: '<:' is an alternate spelling for '['. Insert whitespace between '<' and '::'
/RamalMaisSync/.build/third_party/src/cpprestsdk/Release/include/cpprest/http_client.h: In member function 'void web::http::client::http_client::add_handler(const std::function<pplx::taskweb::http::http_response(web::http::http_request, std::shared_ptrweb::http::http_pipeline_stage)>&)':
/RamalMaisSync/.build/third_party/src/cpprestsdk/Release/include/cpprest/http_client.h:447:44: error: '<::' cannot begin a template-argument list [-fpermissive]
/RamalMaisSync/.build/third_party/src/cpprestsdk/Release/include/cpprest/http_client.h:447:44: note: '<:' is an alternate spelling for '['. Insert whitespace between '<' and '::'
In file included from /RamalMaisSync/.build/third_party/src/cpprestsdk/Release/src/pch/stdafx.h:142:0,
from /RamalMaisSync/.build/third_party/src/cpprestsdk/Release/src/http/client/http_client_msg.cpp:25:
/RamalMaisSync/.build/third_party/src/cpprestsdk/Release/include/cpprest/ws_client.h: At global scope:
/RamalMaisSync/.build/third_party/src/cpprestsdk/Release/include/cpprest/ws_client.h:189:28: error: '<::' cannot begin a template-argument list [-fpermissive]
/RamalMaisSync/.build/third_party/src/cpprestsdk/Release/include/cpprest/ws_client.h:189:28: note: '<:' is an alternate spelling for '['. Insert whitespace between '<' and '::'

The build system is on top of a docker container with debian 7.11, gcc 4.7.2, glibc 2.13 and boost1.55.
Have anyone a track of whats going on?

[garethsb-ghost]

If you have to stick with v2.8.0, see how to solve those errors at c42a369

[BotelhoVinicius]

Thanks @garethsb , I'll stick with this solution until move the buildsystem for the next release tags.

[BotelhoVinicius]

Only that do not fix all gcc 4.7.2 errors, there is any stable version to compile with this version?
There is some company factors that blocks upgrade to gcc 4.9...

[garethsb]

Have you tried latest? I've certainly had v2.10.x series compiling successfully with gcc 4.7.2, though I don't now remember which patch release of v2.10.

[BotelhoVinicius]

Hey @garethsb-sony , tried to compile with cmake 3.1 the version v2.10.14 and got the same error listed on the first message.
Update gcc to 4.9 just for test, and it compiled fine, the problem is around gcc 4.7.2, it's very sad that i cant just update it...

[garethsb]

Looks like it was broken by #1005 getting rid of a few carefully inserted spaces. At the time, the patches for gcc 4.7 were originally applied, @BillyONeal did make clear that support would not be maintained. Although I helped contribute those patches, given gcc 4.7.2 is nearly 7 years old, I can't say I blame him!

[BillyONeal]

@garethsb-sony That commit is not in 2.8.0. 2.8.0 will not be changed; released versions are immutable.

@BotelhoVinicius PRs fixing GCC 4.7.2 will be accepted, but the only systems we regularly test are those described in azure-pipelines.yml (whatever comes with Ubuntu 16.04). If clang-format breaks the fix the affected places will need to be clang-format off'd

[garethsb]

Obviously! The fixes were applied long after 2.8.0, and subsequently broken by the clang-tidy.

[BotelhoVinicius]

Got stuck on line 682 of file ws_client_wspp.cpp , where m_thread.join() is called as const. But if mutable is called on lambda, it stops on this:

internal compiler error: in get_expr_operands, at tree-ssa-operands.c:1035

it's a known bug in GCC 4.7.2 fixed on 4.7.3.
So given this, cuts off the support for 4.7.2 in this project...

[garethsb-ghost]

Did you try this->m_thread as well as marking the lambda as mutable?

[BotelhoVinicius]

Yes ! The problem is on mutable, when marking the lambda as mutable the compiler broke, the only way to resolve ( people seems to make this to fix this issue ) is to make that lambda a function, but i'm not confident in make that change and not cause instability on the implementation...

[BotelhoVinicius]

I'll close this issue.
The final result of the issue is: GCC 4.7.2 is out dated and have several issues and cant follow the releases. Tried several ways to contour the problem, but all get on the same bug on GCC 4.7.2, if someone has a solution for this, please inform.