Pkgconfig file injects -std=c++11 into downstream projects

[WillAyd]

Describe the bug

When compiling a project that uses the SDK as a dependency and resolves said dependency with pkgconfig, the AWS SDK ends up injecting -std=c++11 into the compilation flags of the main project. This appears hard-coded in the configuration:

aws-sdk-cpp/cmake/compiler_settings.cmake

Line 39 in 095b07c

list(APPEND AWS_COMPILER_FLAGS "-fno-exceptions" "-std=c++${CPP_STANDARD}")

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

The dependency should not inject any c++ standard requirements into the parent project

Current Behavior

Compilation fails for projects newer than C++11

Reproduction Steps

Create a module that uses a C++14 feature, like so:

auto doNothing() {
}

int main() {
  return 0;
}

Attempting to compile this with a dependency on aws-cpp-sdk-core will fail:

$ gcc `pkg-config --cflags aws-cpp-sdk-core` main.cc
main.cc:1:1: error: ‘doNothing’ function uses ‘auto’ type specifier without trailing return type
    1 | auto doNothing() {
      | ^~~~
main.cc:1:1: note: deduced return type only available with ‘-std=c++14’ or ‘-std=gnu++14’

Possible Solution

No response

Additional Information/Context

No response

AWS CPP SDK version used

1.11.68

Compiler and Version used

gcc (Ubuntu 15.2.0-4ubuntu4) 15.2.0

Operating System and version

Ubuntu 25.10

[pulimsr]

Hi @WillAyd,

The recommended approach for using the AWS SDK for C++ is building from source rather than using pre-built packages via pkgconfig. This gives you full control over the build configuration.

Please refer to our Building From Source documentation and use the CPP_STANDARD parameter documented in our CMake Parameters guide to set your desired C++ standard (e.g., -DCPP_STANDARD=14).

Building from source with the appropriate CPP_STANDARD setting will generate pkgconfig files compatible with your project's C++ version and resolve your compilation issue.

[WillAyd]

Thanks @pulimsr that is good to know. The challenge I am facing is that I'd like to integrate the AWS SDK for C++ into a project that is not using CMake as its build system generator (in this particular instance, Meson), so its a bit challenging to rely on a source build.

Are there more issues beyond this that are known to prevent users from using pre-built libraries as dependencies?

[gorloffslava]

@WillAyd, meson can use CMake configuration files to detect installed packages, too, if it will help w/ your original issue.

[WillAyd]

Thanks @gorloffslava , and yep I am aware of that. The problem still is that Meson's auto-generated CMake wrappers are a "second tier" of support, so while they work well for smaller projects they struggle with CMake projects of complexity.

There's also limitations around CMake subprojects in Meson being able to detect other third party dependencies (see mesonbuild/meson#8089), so its pretty complicated to rely on a CMake subproject.

Tangentially it might be nice to add Meson support to this library somehow (whether in the source tree here or in the WrapDB), but that is likely a separate issue

[BwL1289]

@WillAyd @pulimsr the issue with this pkgconfig files is that all downstream consumers who will use Cflags defined in this file will automatically get C++ exceptions disabled in their code.

However, it looks like -fno-exceptions doesn't leak to produced CMake configuration files.

[WillAyd]

Thanks @BwL1289 . I noticed that too and mentioned it in the PR for this (see #3614 (comment))

I am by no means a pkgconfig expert, but I wonder if the AWS SDK for C++ should be adding any Cflags at all (excluding the header includes, which make sense)

[sbiscigl]

Hey @WillAyd thanks for going over this issue but as @pulimsr said for this issue you need to change the version of the c++ standard when you build it. Right now the supported way to consume the SDK is via source and building it via cmake. What complications do you face specifically consuming this from source and changing the cpp version?

[WillAyd]

@sbiscigl because my build system is not CMake, it is very difficult to build the AWS SDK from source.

[sbiscigl]

if you are not consuming from source, how do you consume the SDK? where are you getting precompiled binaries from?

[WillAyd]

I am getting the pre-compiled binaries from conda-forge:

https://anaconda.org/conda-forge/aws-sdk-cpp

[sbiscigl]

So for that binary distribution, that is being maintained by other contributors. We love that other add us to different package managers, but for managing build configurations within them, you need to reach out to them.

For instance this is the recipe used to build the SDK. In there you would need to update the configuration CPP_STANDARD to match your language level.

you need to either:

• consume from source and configure cpp level that way.
• update the recipe on conda-forge to accept your configuration/use your configuration.

[WillAyd]

The end user has no control over the recipe, so if I understand what you are suggesting, the AWS SDK needs to be distributed as a different version of every C++ library standard, and projects must link against the version that matches the C++ standard used mainly by the project itself?

I'm not sure I have seen that with other projects, but even if it is the case wouldn't the pkgconfig file still be incomplete? i.e. you'd need to include the standard as part of the library name, so as not to have the binaries potentially overwrite one another on a single host