Vapor build crash swift:5.6.2-centos7

I use docker build

In file included from /build/.build/checkouts/swift-nio/Sources/CNIOLinux/shim.c:27:
/usr/include/unistd.h:1147:35: error: __block attribute not allowed, only allowed on local variables
extern void encrypt (char *__block, int __edflag) __THROW __nonnull ((1));
1 error generated.
In file included from /app/app/swift-nio-ssl/Sources/CNIOBoringSSL/ssl/
In file included from /app/app/swift-nio-ssl/Sources/CNIOBoringSSL/include/CNIOBoringSSL_ssl.h:147:
In file included from /app/app/swift-nio-ssl/Sources/CNIOBoringSSL/include/CNIOBoringSSL_bio.h:66:
In file included from /app/app/swift-nio-ssl/Sources/CNIOBoringSSL/include/CNIOBoringSSL_ex_data.h:114:
/app/app/swift-nio-ssl/Sources/CNIOBoringSSL/include/CNIOBoringSSL_stack.h:446:32: error: no template named 'enable_if_t' in namespace 'std'; did you mean 'enable_if'?
struct DeleterImpl<Stack, std::enable_if_t<StackTraits<Stack>::kIsConst>> {
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/type_traits:1766:12: note: 'enable_if' declared here
    struct enable_if 

@0xTim Can you help me?

Make sure you're not copying over a .build directory and doing a full clean. It also might be that you need to install some dependencies on CentOS but since these are NIO errors, you should raise it with them if that doesn't fix it

swift-nio-ssl no longer supports Centos7 because our upstream dependency (boringssl) dropped support for it. This is beyond our control, sadly.

I wonder how Crypto will handle this case. They're also using a copy of BoringSSL.

I also wonder if it's possible to replace the use of CNIOBoringSSL with CCryptoBoringSSL or even Crypto directly, which will eliminate duplicated BoringSSL copies depended by some libraries (eg. Vapor).

how to fix it ?

How to fix it?
use an old version?

Yes the short term fix is to use an old version. The long term fix is move away from CentOS. Any particular reason you're using it? Since it's 'just' a container it's easy enough to switch away

Crypto should be unaffected for the moment: BoringSSL specifically requires C++14, which is not available in CentOS 7, but Crypto doesn't include libssl, which is where BoringSSL uses C++.

Of course, another option is always to install a custom build environment that does provide C++14, though this isn't always straightforward. However, BoringSSL reserves the right to require newer and newer tooling environments.

It is not possible to replace CNIOBoringSSL with CCryptoBoringSSL for two reasons. Firstly, CCryptoBoringSSL does not include the libssl components, which NIOSSL requires. Secondly, BoringSSL does not provide a stable API. As a result, NIO and Crypto would both have to pin their Boring dependency, which essentially version-locks the two packages. This risks causing dependency hell to adopters, who can end up getting an unbuildable tree.

I use Tencent Cloud serverless and they need centos.
Am I using an older version of vapor? Still limited to the swift-nio-ssl version?
What should I do?

Where does it say the container has to be CentOS?

His web function is based on centos7。
How to adjust the restricted version of swift package, can I restrict only swift-nio-ssl?
Can I solve it by installing C++?

Does vapor have a limited build, deploy platform?
I think we should provide an explanation.

Can a platform support be listed? Or our version limit.
Is our version compliant with SemVer 2.0.0?

I don't understand the question sorry, what web function is based on CentOS 7? And what do you mean by limited build/deploy platform?

List deployable platforms.
For example,
vapor 4.62.0
can deploy Ubuntu18.04, Ubuntu20.04.
does not support centos7.

To deploy Lambda functions to AWS Lambda, you need to compile the code for Amazon Linux which is the OS used on AWS Lambda microVMs, package it as a Zip file, and upload to AWS.

Tencent Cloud serverless support Centos7, not support Ubuntu.

Ahh I see. So you could pin to an old version of Crypto or potentially build it in a different environment as a statically linked executable. This may or may not work depending on dependencies like libgc

No code changes, but he can't build. This is frustrating.