Using aws-cpp-sdk as static libraries in Linux #2184
Replies: 4 comments 2 replies
-
For the record: the duplicate AWSPartitions::PartitionsBlob symbol error went away after passing -DCPP_STANDARD=17 to the aws-cpp-sdk CMake build. |
Beta Was this translation helpful? Give feedback.
-
Hi Paavo, I'm sorry you are experiencing difficulties consuming the SDK. We are still working on our cmake scripts improvement: #1888.
This comes from a recent change to support new endpoints resolution mechanism, we have run the full build on several compilers/platforms (including cpp-11 and cpp-20 standards) before merging this change.
Sorry, I can't comment on this. We know there are customers using the SDK statically, however, every particular build configuration is different, and the library is evolving too. In general, you should be able to consume the library statically.
This most probably comes from our AWS CRT dependency. They are working on addressing this complication, however, we/they cannot tell any approximate estimate.
I don't think there are cyclic dependencies, you should be able to verify it yourself by running this example:
Indeed CRT dependency tree looks complicated.
Best regards |
Beta Was this translation helpful? Give feedback.
-
Thanks for the reply! I'm not sure if it is possible for you to reproduce the build error. Possibly this was because aws-cpp-sdk was compiled in C++11 mode as this is the default, and our code linking to it is compiled in C++17 mode. Not sure if this combination should be even supported, but apparently it worked for a while. When I now added -DCPP_STANDARD=17 to the aws-cpp-sdk build, the error went away. For any case, we are using g++ (Debian 8.3.0-6) 8.3.0 on a common Linux x86_64. The aws-cpp-sdk library was configured and built by:
Our code is also using cmake build, with this list of libraries worked out by trial and error:
Which results in the following commands calls in our build:
|
Beta Was this translation helpful? Give feedback.
-
Hi Paavo, Thanks a lot for your reply and build configuration details. I've modified CPP SDK code to cover such case: #2185 However, in the scope of C++ binary compatibilities, I would strongly suggest to match the toolchain and config you use to build the SDK with the toolchain and build config of your application. Although I cannot imagine any issues in mismatch between 11 and 17 standards, I cannot be sure that there are none. I hope we will improve our dependency tree, cmake and usage of global variables sooner too, but I cannot give any estimates here. Best regards, |
Beta Was this translation helpful? Give feedback.
-
Wanted to clarify what's the status of static build support of aws-cpp-sdk, particularly in Linux? Recently we have had another issue in this area (g_allocator needs to be initialized before first use, which is tricky to achieve with static libs), and now we are facing a multiple definition linker error for AWSPartitions::PartitionsBlob which I suspect is also related. Should we abandon this approach and switch over to using shared libraries?
A part of the problem is that our static build produces 18 .a files with complicated (cyclic?) inter-dependencies, which makes specifying the amount and order of them non-trivial. Is this documented better somewhere?
Beta Was this translation helpful? Give feedback.
All reactions