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:

https://github.com/aws/aws-sdk-cpp/blob/095b07c61ac1e84c181cd077a12218d1629742d9/cmake/compiler_settings.cmake#L39

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 https://github.com/mesonbuild/meson/issues/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 https://github.com/aws/aws-sdk-cpp/pull/3614#discussion_r2500430061)

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

[sbiscigl]

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?

no what im suggesting is that you stop using precompiled binaries and build from source, that is the official supported way to install the SDK. if you want to continuing using the precompiled sources in conda, you will have to work around how they are packaged there. for instance if you want to use any service that isnt in their recipe i.e.

s3;core;transfer;config;identity-management;sts;sqs;sns;monitoring;logs;secretsmanager

you will need to build from source anyway.

[WillAyd]

Without veering too far off topic, I understand that the only supported way to consume the AWS SDK is using CMake and building from scratch. However, I was hoping to keep the issue scoped to the pkgconfig file that is being distributed within this source, which itself is concerned with the distribution of a pre-compiled binary.

Even if its not officially supported, is there any reason why a PR to update it wouldn't be accepted? I am fortunate to only need the services in that recipe, but I am not using CMake. So regardless I'm going down a path that some project isn't going to support; I was just hoping given the scope of pkgconfig and what's in the source tree here it would be an easy "fix"

[eli-schwartz]

Do the header files of this project provide different APIs depending on the -std in use? Because if so, that's probably a bug. And if not, there is no good reason to force an upper bound on the std that other projects use.

[apache-hb]

@WillAyd fwiw I have a port of aws-sdk-cpp to meson here. Its a little hacky but might be a good reference if you need it

[WillAyd]

@apache-hb that's great. I think that would make a good submission to the project if it would be accepted, or as a fallback to the wrapdb

[sbiscigl]

Do the header files of this project provide different APIs depending on the -std in use? Because if so, that's probably a bug.

No the header files do not have a different std in use.

And if not, there is no good reason to force an upper bound on the std that other projects use.

We dont, we recommend you use us from source, and if you build from source you can set whatever std version you want to. if you consume us from a package manager, that manager decides which version of std is going to be enforced.

Even if its not officially supported, is there any reason why a PR to update it wouldn't be accepted?

If I remove and it breaks someones build that has been quietly depending on it for years, then its a problem for them. I'm not against your PR, what concerns me is if I break someone else then while your problem is resolved i've caused someone elses build to break.

[github-actions[bot]]

Greetings! It looks like this issue hasn’t been active in longer than a week. We encourage you to check if this is still an issue in the latest release. Because it has been longer than a week since the last update on this, and in the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please feel free to provide a comment or add an upvote to prevent automatic closure, or if the issue is already closed, please feel free to open a new one.

[apache-hb]

Would it be ok if this behaviour was still the default but there was a cmake option like NO_CPPSTD_IN_PKG_CONFIG flag which would be OFF by default to disable it? Maybe over time the default value for the flag could be switched to ON, this would provide a gradual migration path to those who need it.

[sbiscigl]

Would it be ok if this behaviour was still the default but there was a cmake option like NO_CPPSTD_IN_PKG_CONFIG flag which would be OFF by default to disable it? Maybe over time the default value for the flag could be switched to ON, this would provide a gradual migration path to those who need it.

Yep this sounds like a great idea, and package managers can adopt as they need, will push a update to add that nob