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/tls_method.cc:57:
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>> {
~~~~~^~~~~~~~~~~
enable_if
/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
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
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).
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?
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++?
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
You may try again now with stevapple/swift-scf:nightly Docker image. It comes with GCC 11 which is compatible with C++ standard up to C++20, so Vapor should compile.