[gsoap] Build latest versions

[jgsogo]

closes #7479

[conan-center-bot]

All green in build 1 (dfe84196a44be82465117661c3e5f31eddf3031e):

• gsoap/2.8.114@:
  All packages built successfully! (All logs)

• gsoap/2.8.115@:
  All packages built successfully! (All logs)

• gsoap/2.8.116@:
  All packages built successfully! (All logs)

• gsoap/2.8.117@:
  All packages built successfully! (All logs)

[madebr]

Are the older versions (2.8.103-2.8.106) lost?

[jgsogo]

Are the older versions (2.8.103-2.8.106) lost?

They are available in the remote. If anyone runs conan install gsoap/2.8.103@ it will retrieve the latest revision for that version...

[madebr]

Are the older versions (2.8.103-2.8.106) lost?

They are available in the remote. If anyone runs conan install gsoap/2.8.103@ it will retrieve the latest revision for that version...

I meant, those sources are not available anymore at https://sourceforge.net/projects/gsoap2/files/, so we aren't able to build from source anymore.

[jgsogo]

We will preserve those sources here https://c3i.jfrog.io/artifactory/cci-sources-backup/sources/gsoap/, that's the reason why I created this PR (#7685) so the latest revisions of those versions uses a working path to sources.

[bowb]

This recipe version and the last recipe for 2.8.106 fail to cross compile on x86_64 to armv8. I have to pin the recipe to version gsoap/2.8.106#9b542c0b8a6499155a203d3f06d47cc4 in order to cross compile.

gsoap/2.8.117: ERROR: Package '8a678942469d0284faffa7f3827e4b4cb178253d' build failed
gsoap/2.8.117: WARN: Build folder /opt/shared/buildaarch64/conan/.conan/data/gsoap/2.8.117/_/_/build/8a678942469d0284faffa7f3827
e4b4cb178253d
ERROR: gsoap/2.8.117: Error in build() method, line 44
        cmake.build()
        ConanException: Error 2 while executing cmake --build '/opt/shared/buildaarch64/conan/.conan/data/gsoap/2.8.117/_/_/buil
d/8a678942469d0284faffa7f3827e4b4cb178253d/build_subfolder' '--' '-j6'
CMake Error at CMake/conan.cmake:543 (message):
  Conan install failed='1'
Call Stack (most recent call first):
  CMake/conan.cmake:636 (conan_cmake_install)
  CMakeLists.txt:84 (conan_cmake_run)

[jgsogo]

@bowb is it just 2.8.106? Have you tried other versions?

So far, the current revision has cross-compiled successfully from Macos-x86_64 to Macos-armv8 (https://c3i.jfrog.io/c3i/misc/summary.html?json=https://c3i.jfrog.io/artifactory/misc/logs/pr/7685/5-configs/macos-m1-clang/gsoap/2.8.106/summary.json).

Also, in order to reproduce your scenario, we will need to know at least the profiles you are using.

Thanks!

[bowb]

@bowb is it just 2.8.106? Have you tried other versions?

So far, the current revision has cross-compiled successfully from Macos-x86_64 to Macos-armv8 (https://c3i.jfrog.io/c3i/misc/summary.html?json=https://c3i.jfrog.io/artifactory/misc/logs/pr/7685/5-configs/macos-m1-clang/gsoap/2.8.106/summary.json).

Also, in order to reproduce your scenario, we will need to know at least the profiles you are using.

Thanks!

I think it has something to do with linking against openssl 3.0 as I was just able to build against openssl 1.1.1

Update:

I was able to cross-compile against openssl 3.0.0 with conan create so it must be something in my cross compile build scripts that it doesn't like.

[bowb]

@bowb is it just 2.8.106? Have you tried other versions?

So far, the current revision has cross-compiled successfully from Macos-x86_64 to Macos-armv8 (https://c3i.jfrog.io/c3i/misc/summary.html?json=https://c3i.jfrog.io/artifactory/misc/logs/pr/7685/5-configs/macos-m1-clang/gsoap/2.8.106/summary.json).

Also, in order to reproduce your scenario, we will need to know at least the profiles you are using.

Thanks!

I am still having issues when trying to cross compile install from a conanfile with openssl 3.0

Configuration (profile_host):

[settings]
arch=armv8
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=9
os=Linux
os_build=Linux
os_target=Linux
[options]
[build_requires]
[env] 
AR=aarch64-linux-gnu-ar
AS=aarch64-linux-gnu-as
CC=aarch64-linux-gnu-gcc
CHOST=aarch64-linux-gnu
CONAN_CMAKE_FIND_ROOT_PATH=/usr/aarch64-linux-gnu
CXX=aarch64-linux-gnu-g++
LD=aarch64-linux-gnu-ld
PATH=[/usr/aarch64-linux-gnu/bin]
RANLIB=aarch64-linux-gnu-ranlib
STRIP=aarch64-linux-gnu-strip

Configuration (profile_build):

[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=9
os=Linux
os_build=Linux
[options]
[build_requires]
[env]

conanfile.txt

[requires]

gsoap/2.8.106
openssl/3.0.0

[generators]
cmake_paths

[options]

I actually have the profile in files and run

 conan install --update --profile:host /tmp/conan_aarch64_gcc9_profile.txt  --profile:build /tmp/conan_x86_64_gcc9_profile.txt /opt --build missing

ERROR:

WARN: gsoap/2.8.106: requirement openssl/1.1.1l overridden by your conanfile to openssl/3.0.0 
zlib/1.2.11: WARN: Can't update, no package in remote
openssl/3.0.0: WARN: Can't update, no package in remote
ERROR: openssl/1.1.1l: option 'no_fips' doesn't exist
Possible options are ['no_threads', 'shared', 'fPIC', 'no_asm', 'enable_weak_ssl_ciphers', '386', 'no_stdio', 'no_tests', 'no_sse2', 'no_bf', 'no_cast', 'no_des', 'no_dh', 'no_dsa', 'no_hmac', 'no_md5', 'no_mdc2', 'no_rc2', 'no_rsa', 'no_sha', 'no_async', 'no_dso', 'no_aria', 'no_blake2', 'no_camellia', 'no_chacha', 'no_cms', 'no_comp', 'no_ct', 'no_deprecated', 'no_dgram', 'no_engine', 'no_filenames', 'no_gost', 'no_idea', 'no_md4', 'no_ocsp', 'no_pinshared', 'no_rmd160', 'no_sm2', 'no_sm3', 'no_sm4', 'no_srp', 'no_srtp', 'no_ssl', 'no_ts', 'no_whirlpool', 'no_ec', 'no_ecdh', 'no_ecdsa', 'no_rfc3779', 'no_seed', 'no_sock', 'no_ssl3', 'no_tls1', 'openssldir']

It appears to be trying to build against openssl/1.1.1l witch might be caused by the change to the gsoap.cmake file. I have had other issues with cmake find and openssl 3.0 in cross compiling where it was finding the system installed openssl 1.1.1

find_package(OpenSSL REQUIRED)

[madebr]

@bowb
I can reproduce your problem. I think it's a conan issue.
This problem occurs with every recipe that has a build requirement on itself, and requires openssl.
What do you think @jgsogo ?

[jgsogo]

Indeed, it looks like an issue on the Conan side. This is my understanding of what happens:

At the time of building the graph with the overrides, Conan is able to override only the openssl version in the host context, but the one in build context is the same. This wouldn't be a big problem, we are interested in the resulting library for the host context and we are telling Conan to override the version there, so it is working as expected. We can ask "what if we want to override the version in the build-requires?", but it would be a different feature.

We are able to build the graph we are looking for, but here it comes the problem: Conan generates a set of options for the openssl version in the host context (with no_fips option) and then it tries to apply that same set of options to the recipe in the build context... and fails, because it is openssl/1.1.1l in the build context and it doesn't have that option.

This issue happens when using two-profiles (two contexts) and not only for recipes that require directly themselves... I can reproduce when it is a transitive dep:

[requires]
openssl/3.0.0

[build_requires]
cmake/3.21.3

conan install conanfile.txt --profile:host=default --profile:build=default