如何在Solaris上构建AWS C ++ SDK? [英] How to build AWS C++ SDK on Solaris?

问题描述

我正在尝试在Solaris上构建AWS C ++ SDK，但无法成功完成.

I am trying to build the AWS C++ SDK on Solaris, but I cannot do so successfully.

我在AWS C ++ SDK页面上发现了此公开问题那说可能，但是没有关于它的指南，我希望这里有人可以提供帮助.

I found this open issue on the AWS C++ SDK page that says it is possible, but there is no guide on it and I am hoping somebody here can help.

这是我用来构建它的命令:

Here is the command I use to build it:

$ cmake ../aws-sdk-cpp/ -DCMAKE_BUILD_TYPE=Debug -DBUILD_ONLY="s3"

以下是输出:

-- TARGET_ARCH not specified; inferring host OS to be platform compilation target
-- Building AWS libraries as shared objects
-- Generating linux build config
-- Building project version: 1.7.134
-- Configuring done
-- Generating done
-- Build files have been written to: /workspace/dmoini/sdk_build/.deps
gmake: Warning: File 'Makefile' has modification time 267 s in the future
gmake[1]: Warning: File 'CMakeFiles/Makefile2' has modification time 267 s in the future
gmake[2]: Warning: File 'CMakeFiles/AwsCCommon.dir/progress.make' has modification time 267 s in the future
gmake[2]: warning:  Clock skew detected.  Your build may be incomplete.
gmake[2]: Warning: File 'CMakeFiles/AwsCCommon.dir/progress.make' has modification time 267 s in the future
[  4%] Performing build step for 'AwsCCommon'
[  1%] Building C object CMakeFiles/aws-c-common.dir/source/array_list.c.o
In file included from /usr/include/stdio.h:37:0,
                 from /workspace/dmoini/sdk_build/.deps/build/src/AwsCCommon/include/aws/common/common.h:22,
                 from /workspace/dmoini/sdk_build/.deps/build/src/AwsCCommon/include/aws/common/array_list.h:18,
                 from /workspace/dmoini/sdk_build/.deps/build/src/AwsCCommon/source/array_list.c:16:
/opt/gcc-5.1.0/lib/gcc/i386-pc-solaris2.11/5.1.0/include-fixed/sys/feature_tests.h:405:2: error: #error "Compiler or options invalid for pre-UNIX 03 X/Open applications        and pre-2001 POSIX applications"
 #error "Compiler or options invalid for pre-UNIX 03 X/Open applications \
  ^
gmake[5]: *** [CMakeFiles/aws-c-common.dir/build.make:63: CMakeFiles/aws-c-common.dir/source/array_list.c.o] Error 1
gmake[4]: *** [CMakeFiles/Makefile2:484: CMakeFiles/aws-c-common.dir/all] Error 2
gmake[3]: *** [Makefile:139: all] Error 2
gmake[2]: *** [CMakeFiles/AwsCCommon.dir/build.make:112: build/src/AwsCCommon-stamp/AwsCCommon-build] Error 2
gmake[1]: *** [CMakeFiles/Makefile2:68: CMakeFiles/AwsCCommon.dir/all] Error 2
gmake: *** [Makefile:84: all] Error 2
CMake Error at CMakeLists.txt:193 (message):
  Failed to build third-party libraries.

此外，这是我的系统信息:

Additionally, here is my system information:

$ uname -a
SunOS bld-dmoini-01-sv4b 5.11 omnios-r151020-4151d05 i86pc i386 i86pc

非常感谢所有帮助/指导.

Any and all help/guidance is greatly appreciated.

推荐答案

我已经在Solaris 11.4的常规安装上成功完成了AWS C ++ SDK的编译，并发现了可能导致上述问题的几个问题.

I've successfully completed compiling the AWS C++ SDK on a stock install of Solaris 11.4, and found several issues that could cause the problems noted.

从干净的源代码树开始.

Start with a clean source tree.

删除-Werror

Remove -Werror

要做的第一件事是删除-Werror编译器选项.默认情况下，Solaris 11.4上安装的OpenSSL版本具有许多不赞成使用的功能，并且-Werror选项会导致在遇到不赞成使用的版本时使构建失败.我使用了从AWS开发工具包源树的最顶层目录运行的find命令来删除所有-Werror选项:

The first thing do to is remove the -Werror compiler options. The version of OpenSSL installed by default on Solaris 11.4 has quite a few deprecated functions, and the -Werror option causes the build to fail when it runs into those deprecations. I used this find command run from the topmost directory of the AWS SDK source tree to remove all the -Werror options:

vi `find . | xargs grep -l Werror`

您将获得大约三个或四个文件，其中只有两个实际上将-Werror设置为编译器选项.只需从这些文件中删除"-Werror"字符串即可.

You'll get about three or four files, only two of which are actually setting the -Werror as a compiler option. Just remove the "-Werror" strings from those files.

修复POSIX定义

然后在最顶层目录中运行cmake ..它将失败，因为它下载的cmake文件将具有不正确的POSIX命令行选项--D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=500. 500是错误的. _POSIX_C_SOURCE=200809L对应于_XOPEN_SOURCE=700. _XOPEN_SOURCE=500是 SUSv2，大约在1997年.用C99编译SUSv2应用程序是不合适的.

Then run cmake . in the topmost directory. It will fail because the cmake files that it downloads will have improper POSIX command-line options - -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=500. That 500 is wrong. _POSIX_C_SOURCE=200809L corresponds to _XOPEN_SOURCE=700. _XOPEN_SOURCE=500 is SUSv2, circa 1997. It's not proper to compile a SUSv2 application with C99.

每个 2.2.1严格符合POSIX应用，第8段:

Per 2.2.1 Strictly Conforming POSIX Application, paragraph 8:

1. 对于C编程语言，应在包含任何标头之前将_POSIX_C_SOURCE定义为200809L

1. For the C programming language, shall define _POSIX_C_SOURCE to be 200809L before any header is included

和 2.2.4严格符合XSI应用程序，第8段:

1. 对于C编程语言，应在包含任何标头之前将_XOPEN_SOURCE定义为700

1. For the C programming language, shall define _XOPEN_SOURCE to be 700 before any header is included

每个 Illumos sys/feature_tests.h文件(基于OpenSolaris，它也是Solaris 11的基础):

Per the Illumos sys/feature_tests.h file (based on OpenSolaris, which was also the basis for Solaris 11):

 * Feature Test Macro                                Specification
 * ------------------------------------------------  -------------
 * _XOPEN_SOURCE                                         XPG3
 * _XOPEN_SOURCE && _XOPEN_VERSION = 4                   XPG4
 * _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED = 1           XPG4v2
 * _XOPEN_SOURCE = 500                                   XPG5
 * _XOPEN_SOURCE = 600  (or POSIX_C_SOURCE=200112L)      XPG6
 * _XOPEN_SOURCE = 700  (or POSIX_C_SOURCE=200809L)      XPG7

通过git下载的文件cmake需要进行

The files cmake downloads via git need to be edited:

vi `find .deps | xargs grep -l XOPEN_SOURCE`

将任何-D_XOPEN_SOURCE=500更改为-D_XOPEN_SOURCE=700，然后重新运行cmake ..这次应该可以成功完成.

Change any -D_XOPEN_SOURCE=500 to -D_XOPEN_SOURCE=700 and rerun cmake .. It should complete successfully this time.

然后运行gmake. (我发现gmake在Solaris上几乎对所有开放源代码项目都更好，因为许多开放源代码项目都使用特定于GNU的make扩展.)

Then run gmake. (I find gmake works much better on Solaris for just about all open source projects, as many open source projects use GNU-specific make extensions.)

现在，您可以修复遇到的所有损坏的源代码.

Now you get to fix any broken source code you run into.

修复损坏的源代码

1

The file aws-sdk-cpp/aws-cpp-sdk-core/source/platform/linux-shared/OSVersionInfo.cpp has the following wrong code:

Aws::String ComputeOSVersionString()
{
    utsname name;
    int32_t success = uname(&name);

对于POSIX ，正确的类型是struct utsname，不只是utsname:

Per POSIX, the correct type is struct utsname, not just utsname:

 int uname(struct utsname *name);

AWS代码必须为:

Aws::String ComputeOSVersionString()
{
    struct utsname name;
    int success = uname(&name);

不，给定是的，一个实际的while (!feof())循环...

Yes, an actual while (!feof()) loop...

2

文件 在/usr/include/sys/regset.h 中注册#define.

The file aws-sdk-cpp/aws-cpp-sdk-mediaconvert/include/aws/mediaconvert/model/M2tsSegmentationMarkers.h uses an enumeration with the value EBP, which conflicts with the EBP register #define in /usr/include/sys/regset.h.

我只是将其更改为EBP_HASH，因为这似乎与代码有些匹配:

I just changed it to EBP_HASH as that seems to match the code somewhat:

vi `find . | xargs grep -l EBP`

3

文件 ES注册</usr/include/sys/regset.h 中的c35>.我刚刚添加了

The file aws-sdk-cpp/aws-cpp-sdk-route53domains/include/aws/route53domains/model/CountryCode.h creates an enumeration value ES that conflicts with the ES register #define in /usr/include/sys/regset.h. I just added

#ifdef ES
#undef ES
#endif 

，编译继续.我不知道#undef是否可能损坏了任何东西.

and the compile continued. I don't know if that #undef could have broken anything.

4

文件 ES，GS和SS在/usr/include/sys/regset.h 中注册#define.

The file aws-sdk-cpp/aws-cpp-sdk-waf/include/aws/waf/model/GeoMatchConstraintValue.h has ES, GS, and SS enumeration value that conflict with the ES, GS, and SS register #define's in /usr/include/sys/regset.h.

再次，我只添加了几个#undef:

Again, I just added a few more #undef's:

#ifdef ES
#undef ES
#endif

#ifdef GS
#undef GS
#endif

#ifdef SS
#undef SS
#endif

我真的很想知道为什么#include被包含在AWS开发工具包的几乎所有内容中.

I'm really wondering why sys/regset.h is being #include'd in just about everything in the AWS SDK.

5

Same problem in aws-sdk-cpp/aws-cpp-sdk-waf-regional/include/aws/waf-regional/model/GeoMatchConstraintValue.h. Same fix, add:

#ifdef ES
#undef ES
#endif

#ifdef GS
#undef GS
#endif

#ifdef SS
#undef SS
#endif

请注意，在SPARC硬件上进行编译意味着sys/regset.h中的#define值将完全不同，并且任何错误也将完全不同.

Note that compiling on SPARC hardware means the #define value from sys/regset.h will be completely different, and any errors will be completely different.

6

文件 POSIX 路径名变量值标准(轰炸我的人):

The file aws-sdk-cpp/aws-cpp-sdk-core-tests/utils/FileSystemUtilsTest.cpp incorrectly assumes the POSIX NAME_MAX value is defined. Per the POSIX Pathname Variable Values standard (bolding mine):

路径名变量值

以下列表中的值可以是 实施，或者从一个路径名到另一个路径名可能不同.例如， 文件系统或目录可能具有不同的特征.

The values in the following list may be constants within an implementation or may vary from one pathname to another. For example, file systems or directories may have different characteristics.

以下列表中的一个符号常量的定义 从<limits.h>标头中的应当省略 对应值等于或大于等于的实现 低于规定的最小值，但该值可能会根据 应用到的文件.特定值支持的实际值 路径名应由pathconf()函数提供.

A definition of one of the symbolic constants in the following list shall be omitted from the <limits.h> header on specific implementations where the corresponding value is equal to or greater than the stated minimum, but where the value can vary depending on the file to which it is applied. The actual value supported for a specific pathname shall be provided by the pathconf() function.

再次:定义... 应省略 ...值可能会有所不同".

Again: the "definition ... shall be omitted ... where the value can vary".

AWS代码错误地假定NAME_MAX 必须.

The AWS code wrongly assumes NAME_MAX must be #define'd.

我只是硬编码了255的值来克服这一点，尽管使用_POSIX_NAME_MAX或_XOPEN_NAME_MAX之类的方法可能更好.

I just hardcoded a value of 255 to get past this point, although using something like _POSIX_NAME_MAX or _XOPEN_NAME_MAX is probably better.

7

文件std::shared_ptr为8个字节，则aws-sdk-cpp/ws-cpp-sdk-core-tests/http/HttpClientTest.cpp 似乎是错误的. 这个问题和答案提供了一个很好的例子说明了这是怎么回事.

File aws-sdk-cpp/ws-cpp-sdk-core-tests/http/HttpClientTest.cpp seems to be incorrectly assuming a std::shared_ptr will be 8 bytes. This question and answer provides a good example of how that's wrong.

我只是忽略了此错误，因为它只是一个测试，然后继续执行gmake -i，该错误成功完成了.

I just ignored this error as it's just a test and continued with gmake -i, which completed successfully outside of this one error.

这篇关于如何在Solaris上构建AWS C ++ SDK?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！