Can't build x86 on an x86-64 machine because of third-party

[kmaragon]

What platform/OS are you using?

Linux x86-64 machine with -m32 build

What compiler are you using? what version?

gcc / clang are both affected

What's your CMake arguments?

The important ones are CMAKE_CXX_FLAGS="-m32", CMAKE_SHARED_LINKER_FLAGS="-m32", and CMAKE_CXX_FLAGS="-m32" and CMAKE_C_FLAGS="-m32"

Can you provide a TRACE level log? (sanitize any sensitive information)

not really but there's this: https://travis-ci.org/kmaragon/conan-aws-sdk-cpp/jobs/503283625

Ultimately the issue is that when calling ExternalProject_Add at https://github.com/aws/aws-sdk-cpp/blob/master/third-party/cmake/BuildAwsEventStream.cmake#L45
https://github.com/aws/aws-sdk-cpp/blob/master/third-party/cmake/BuildAwsChecksums.cmake#L38
and https://github.com/aws/aws-sdk-cpp/blob/master/third-party/cmake/BuildAwsCCommon.cmake#L39

The build doesn't forward the aformentioned flags. it seems like there was a commit:
312db5e
that likely largely resolved the issue for OSX. It only forwards C_FLAGS but I assume these 3 libraries are pure C from their names so that's sufficient. But the fix wasn't rolled out to any case except OSX.

The result is that when building aws-sdk-cpp with -m32 on Linux, with either clang or gcc, you get a nicely compiled set of 32 bit aws cpp libraries that can't be loaded because they ultimately depend on these 3 c libraries which have all been built for 64 bit only.

[singku]

Looking at the Travis job, AWS SDK for CPP has been built and installed correctly. It failed when building the example project because it can't locate the 3rd-party libraries.
CMAKE_C_FLAGS is actually passed to 3rd-party libraries and they are installed in lib instead of lib64 directory. So I don't think this is the cause.

[kmaragon]

It found the library. But it couldn't link:
https://travis-ci.org/kmaragon/conan-aws-sdk-cpp/jobs/503283625#L2103
Because the third party library was incompatible.

[singku]

What I meant is based on that build output, AWS SDK CPP itself can link against third parties. Means both of them must be successfully built to 32bit libraries.

But the last step bin/example, which is not part of SDK, can't locate the correct third-party libraries. You should check if -m32 was passed to CMakeList.txt of that project (bin/example)

[kmaragon]

it's building a static library. It never actually tries to link aws sdk cpp itself to the c libraries until it needs to. the example is the first time it needs to.

[kmaragon]

I added verbose logging to the example compilation:

https://travis-ci.org/kmaragon/conan-aws-sdk-cpp/jobs/503385497#L2135

worth noting is that only the c libraries are skipped. The AWS SDK C++ libraries are not.

[kmaragon]

And here you can see the C++ library is also being build with -m32
https://travis-ci.org/kmaragon/conan-aws-sdk-cpp/jobs/503387867

[kmaragon]

oh I think I just discovered the problem... the CMAKE_C_FLAGS are injected into the project. And the 3rd party libs are set up before the project is even declared in the root CMake file

[kmaragon]

Also this seems redundant:

cmake_minimum_required (VERSION 3.1)
...
# 3.0 or higher is strongly suggested; build settings (target_compile_options/etc...) sometimes do not get propagated properly under certain conditions prior to this version
# Making this a hard requirement is potentially disruptive to existing customers who aren't affected by the bad behavior though, so just warn for now
if(CMAKE_MAJOR_VERSION LESS 3)
    message(WARNING "Building with CMake 3.0 or higher is strongly suggested; current version is ${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION}")
endif()

[kmaragon]

ok that's not the problem.

[kmaragon]

Ok - I think it's because those flags are set on the directory - not globally in CMAKE_C_FLAGS. So if I were to include aws-sdk-cpp inline with a submodule and added it with add_subdirectory then if I add a directory property set via: add_compile_options those options won't cascade down. I think that's about what conan is doing and why this isn't cascading down. For now, for the package build, I can globally set CMAKE_C_FLAGS.

But it would be swell if the CMake file would use directory properties:
https://cmake.org/cmake/help/v3.12/manual/cmake-properties.7.html#properties-on-directories
specifically:
COMPILE_DEFINITIONS
COMPILE_OPTIONS
from the current dir and pass those on appropriately to the ExternalProject. But at this scope, there's no problem infecting the entire build with these CMAKE_C_FLAGS and CMAKE_CXX_FLAGS set globally since that's ultimately my goal anyway to produce a 32 bit build.

[kmaragon]

Never mind. It's still not cascading down even explicitly setting CMAKE_C_FLAGS