Closed marvin-the-mathematician closed 4 months ago
It seems the b2 fix (https://github.com/bfgroup/b2/pull/394/commits/f6954202121a8993bc48f41ef90caf0c3682706b) is only present in the latest release of b2, that is 5.2.0 (and not in either 5.0.0 or in 5.1.0):
git merge-base 2d756eb245e9898cbeb3212ca1716038927329a8 --is-ancestor 5.2.0 && echo yes || echo no
yes
and
git merge-base 2d756eb245e9898cbeb3212ca1716038927329a8 --is-ancestor 5.1.0 && echo yes || echo no
no
So is there any chance of adding a recipe for b2/5.2.0 and then making that a dependency of boost/1.85.0? If not, any chance that I could be pointed at the relevant docs to help me achieve a similar outcome at my end? I am relatively new to Conan package management so I might need a bit of hand-holding (sorry). I do have a Conan repo set up in a private Artifactory instance though and so forking (https://github.com/conan-io/conan-center-index), making the necessary changes, and pushing the resulting packages up to my private conan repository is definitely a possibility. Many thanks.
Hi @marvin-the-mathematician
The PR https://github.com/conan-io/conan-center-index/pull/24288 was merged hours ago, so the new b2/5.2.0
version should already be in ConanCenter. Can you please try updating your dependencies? In your case, if working from a fork, it means pulling the latest conan-center-index
changes, and building latest b2
from source.
Thanks for the prompt reply (I really appreciate it).
I did see that there was a b2/5.2.0 recipe here (https://github.com/conan-io/conan-center-index/blob/master/recipes/b2/config.yml), but the boost/1.85.0 recipe currently looks to have a pinned tool_requires
dependency on b2/4.10.1 (https://conan.io/center/recipes/boost?version=). And so I am currently relying on that pinned dependency to pick up the right version of b2
. I am only requiring boost/1.85.0 in my current conan install ...
invocation.
Apologies, but my Conan skills don't currently stretch to figuring out how to override that pinned dependency. Is there a way to override it?
You might be able to overwrite it adding to your profile:
...
[tool_requires]
b2/5.2.0
And then passing that profile to your conan
command.
I guess the recipe for boost in conan-center-index
will soon update to the latest b2
, but in the meantime that might help.
Unfortunately using to following conan install ...
invocation below doesn't work:
RUN Import-Module C:\BuildTools\Common7\Tools\Microsoft.VisualStudio.DevShell.dll; `
Enter-VsDevShell -VsInstallPath C:\BuildTools -SkipAutomaticLocation -DevCmdArguments '"-arch=x64 -no_logo"'; `
cmake --version; `
python --version; `
conan --version; `
conan install `
--requires=boost/1.85.0 `
--tool-requires=b2/5.2.0 `
--profile:all=windows-x86_64-msvc194-release `
--options:all='*:shared=False' `
--build='missing:*'
Both b2/4.10.1 and b2/5.2.0 are installed side by side and the former gets used during the boost/1.85.0 build (leading to the issue as reported). I will try overriding the version of b2
in the profile, but I suspect I'll get a similar result.
There is a narrow possibility that I may be able to specify the vc143
toolset through a b2
option, but if that doesn't work I suspect I'll have to fork the recipe, make the necessary patch and host the resulting packages (and recipes) in a private remote Conan cache. A little annoying that such a standard dependency, i.e. boost, is causing me so much trouble (it has to be said) and I suspect this will impact many Windows CI pipelines that use the Visual Studio 2022 version 17.x build tools. But until I figure out how to control the exact version of the Visual Studio 2022 build tools that get installed into the Windows Docker image I am somewhat at the mercy of Microsoft's (strange) versioning strategies. Thanks for the help in any case.
I would appreciate this issue being kept open until the vanilla Visual Studio 2022 version 17.10 build of boost/1.850 is possible without issue. Thanks.
Good news! You were right (and I was wrong) :-) Adding:
...
[tool_requires]
b2/5.2.0
to the windows-x86_64-msvc194-release
conan profile used in the conan install ...
invocation above did have the effect of overriding the b2/4.10.1
dependency of the boost/1.85.0
recipe. I am currently waiting to see if the actual build succeeds... Fingers crossed. Is this behaviour (that profile settings override other settings) documented somewhere? It would be good to cement my new found knowledge on the subject of setting precedence. In any case, I'll let you know whether the build succeeds in due course. Thanks again.
Yes, the difference is that
--requires=boost/1.85.0 `
--tool-requires=b2/5.2.0 `
Installs the tool-requires for yourself but not for boost, while the profile [tool_requires]
inject the tool-requires in all packages, including boost.
Okay. Thanks for the clarification. Just to confirm, I was able to build and package boost/1.85.0
using the Visual Studio 2022 version 17.10 build tools (and the given conan profile - arch=x86_64, build_type=Release, compiler=msvc, compiler.cppstd=20, compiler.version=194, os=Windows, etc.) using the suggested workaround above. See the logs below:
...
Performing configuration checks
- default address-model : 64-bit [1]
- default architecture : x86 [1]
- compiler supports SSE2 : yes [2]
- compiler supports SSE4.1 : yes [2]
- cxx11_static_assert : yes [2]
- has synchronization.lib : yes [2]
- cxx11_variadic_templates : yes [2]
- cxx11_decltype : yes [2]
- GCC libquadmath and __float128 support : no [2]
- cxx11_hdr_ratio : yes [2]
- cxx11_template_aliases : yes [2]
- cxx11_char16_t : yes [2]
- cxx11_char32_t : yes [2]
- cxx20_hdr_concepts : yes [2]
- cpp_lib_memory_resource : yes [2]
warning: non-free usage requirements <boost.cobalt.pmr>std ignored
warning: in main-target boost_cobalt at libs\cobalt\build\Jamfile:73
- has std::atomic_ref : yes [2]
- has statx : no [2]
- has statx syscall : no [2]
- has BCrypt API : yes [2]
- has init_priority attribute : no [2]
- has stat::st_blksize : no [2]
- has stat::st_mtim : no [2]
- has stat::st_mtimensec : no [2]
- has stat::st_mtimespec : no [2]
- has stat::st_birthtim : no [2]
- has stat::st_birthtimensec : no [2]
- has stat::st_birthtimespec : no [2]
- has fdopendir(O_NOFOLLOW) : no [2]
- has dirent::d_type : no [2]
- has POSIX *at APIs : no [2]
- has fallocate : no [2]
- cxx11_rvalue_references : yes [2]
- cxx11_scoped_enums : yes [2]
- cxx11_noexcept : yes [2]
- cxx11_nullptr : yes [2]
- cxx11_defaulted_functions : yes [2]
- cxx11_defaulted_moves : yes [2]
- cxx11_deleted_functions : yes [2]
- cxx11_function_template_default_args : yes [2]
- cxx11_final : yes [2]
- cxx11_override : yes [2]
- has_icu builds : no [2]
- zlib : yes [2]
- bzip2 : yes [2]
- cxx11_constexpr : yes [2]
- cxx11_hdr_tuple : yes [2]
- cxx11_basic_alignas : yes [2]
- cxx11_auto_declarations : yes [2]
- cxx11_hdr_functional : yes [2]
- cxx11_hdr_type_traits : yes [2]
- cxx11_range_based_for : yes [2]
- cxx11_smart_ptr : yes [2]
- native atomic int32 supported : yes [2]
- has message compiler : yes [2]
- native syslog supported : no [2]
- pthread supports robust mutexes : no [2]
- Boost.Regex is header-only : yes [2]
- compiler supports SSSE3 : yes [2]
- compiler supports AVX2 : yes [2]
- cxx11_lambdas : yes [2]
- gcc visibility : no [2]
- sfinae_expr : yes [2]
- cxx11_unified_initialization_syntax : yes [2]
- cxx11_hdr_initializer_list : yes [2]
- cxx11_hdr_chrono : yes [2]
- cxx11_thread_local : yes [2]
- cxx11_numeric_limits : yes [2]
- cxx11_hdr_array : yes [2]
- cxx11_hdr_atomic : yes [2]
- cxx11_allocator : yes [2]
- cxx11_explicit_conversion_operators : yes [2]
- cxx14_decltype_auto : yes [2]
- cxx14_generic_lambdas : yes [2]
- cxx14_return_type_deduction : yes [2]
- cxx14_variable_templates : yes [2]
- long double support : yes [2]
- Has Large File Support : yes [2]
- Has attribute init_priority : no [2]
- std_wstreambuf builds : yes [2]
- std_wstreambuf : yes [2]
- libbacktrace builds : no [2]
- cxx11_rvalue_references : yes [3]
- libbacktrace builds : no [3]
- addr2line builds : no [2]
- addr2line builds : no [3]
- WinDbg builds : yes [2]
- WinDbg builds : yes [3]
- WinDbgCached builds : yes [2]
- BOOST_COMP_GNUC >= 4.3.0 : no [2]
- cxx11_hdr_thread : yes [2]
- cxx11_hdr_mutex : yes [2]
- cxx11_hdr_regex : yes [2]
[1] msvc-14.3
[2] msvc-14.3/rls/bst.l-off/bst.l-off/cxstd-20-iso/lnk-sttc/pythn-3.12/thrdp-wn32/thrd-mlt/vsblt-hdn
[3] msvc-14.3/rls/bst.l-off/bst.l-off/bld-no/cxstd-20-iso/lnk-sttc/pythn-3.12/thrdp-wn32/thrd-mlt/vsblt-hdn
Component configuration:
- atomic : building
- charconv : building
- chrono : building
- cobalt : building
- container : building
- context : building
- contract : building
- coroutine : building
- date_time : building
- exception : building
- fiber : not building
- filesystem : building
- graph : building
- graph_parallel : not building
- headers : not building
- iostreams : building
- json : building
- locale : building
- log : building
- math : building
- mpi : not building
- nowide : building
- program_options : building
- python : not building
- random : building
- regex : building
- serialization : building
- stacktrace : building
- system : building
- test : building
- thread : building
- timer : building
- type_erasure : building
- url : building
- wave : building
boost/1.85.0: Package '5b206d5bc0af0b57e57d2785127[443](https://gitlab.corp.five.ai/pipelines/scenario-database-and-sdl/scenario-definition-cpp/-/jobs/9796950#L443)f36883ffbb' built
boost/1.85.0: Build folder C:\Users\ContainerAdministrator\.conan2\p\b\boost1a02c9af7b2b2\b\build-release
boost/1.85.0: Generating the package
boost/1.85.0: Packaging in folder C:\Users\ContainerAdministrator\.conan2\p\b\boost1a02c9af7b2b2\p
boost/1.85.0: Calling package()
boost/1.85.0: package(): Packaged 15275 '.hpp' files
boost/1.85.0: package(): Packaged 149 '.h' files
boost/1.85.0: package(): Packaged 323 '.ipp' files
boost/1.85.0: package(): Packaged 17 files
boost/1.85.0: package(): Packaged 2 '.inc' files: cpp_re.inc, strict_cpp_re.inc
boost/1.85.0: package(): Packaged 41 '.lib' files
boost/1.85.0: package(): Packaged 1 '.txt' file: LICENSE_1_0.txt
boost/1.85.0: Created package revision 897f9ab02d2f953eff5e3f1ee4f9be5d
boost/1.85.0: Package '5b206d5bc0af0b57e57d2785127443f36883ffbb' created
boost/1.85.0: Full package reference: boost/1.85.0#a68[463](https://gitlab.corp.five.ai/pipelines/scenario-database-and-sdl/scenario-definition-cpp/-/jobs/9796950#L463)169d04e86aceb21ffa9deb6858:5b206d5bc0af0b57e57d2785127443f36883ffbb#897f9ab02d2f953eff5e3f1ee4f9be5d
boost/1.85.0: Package folder C:\Users\ContainerAdministrator\.conan2\p\b\boost1a02c9af7b2b2\p
boost/1.85.0: Disabled magic autolinking (smart and magic decisions)
WARN: deprecated: Usage of deprecated Conan 1.X features that will be removed in Conan 2.X:
WARN: deprecated: 'env_info' used in: bzip2/1.0.8, b2/5.2.0, boost/1.85.0
WARN: deprecated: 'cpp_info.names' used in: bzip2/1.0.8, zlib/1.3.1, boost/1.85.0
WARN: deprecated: 'cpp_info.build_modules' used in: bzip2/1.0.8
WARN: deprecated: 'cpp_info.filenames' used in: boost/1.85.0
WARN: deprecated: 'user_info' used in: boost/1.85.0
======== Finalizing install (deploy, generators) ========
cli: Generating aggregated env files
cli: Generated aggregated env files: ['conanbuild.bat', 'conanrun.bat']
Install finished successfully
So that confirms that the problem was (as suspected) with the b2
dependency. Many thanks for your help. Hopefully, the dependency of boost/1.85.0
on b2/4.10.1
can be bumped up to b2/5.2.0
in due course.
I think this might be good feedback for @grafikrobot.
At the moment I don't see any PR updating the boost recipe tool_require
to latest b2
.
As it is a major version, is there any breaking behavior that should be taken into account? Can the tool_requires
be updated to latest b2/5.2.0
even for older boost versions?
I think this might be good feedback for @grafikrobot.
Thank you for the ping.
At the moment I don't see any PR updating the boost recipe
tool_require
to latestb2
. As it is a major version, is there any breaking behavior that should be taken into account? Can thetool_requires
be updated to latestb2/5.2.0
even for older boost versions?
I test B2 releases for Boost versions all the way back to 1.66.0 (for example: https://dev.azure.com/bfgroup/B2/_build/results?buildId=1287&view=logs&j=29508707-2082-586a-124b-f0598eaa1117&t=969d561e-c78e-519e-0c7d-2065d1cf56b7). But the testing is superficial as it doesn't compile anything. It only checks that the build commands generate.
Hence.. Yes, it's likely possible you can update current and previous Boost releases to use the current B2. But I can't fully guarantee it will work identically. :-)
Hence.. Yes, it's likely possible you can update current and previous Boost releases to use the current B2. But I can't fully guarantee it will work identically. :-)
Thanks for the feedback!
Sure, things might not be identical, but to make sure, are you aware of some specific changes that will result in very different binaries? Or if things work and compile, we can expect that the binaries will keep being reasonably binary compatible?
Sure, things might not be identical, but to make sure, are you aware of some specific changes that will result in very different binaries? Or if things work and compile, we can expect that the binaries will keep being reasonably binary compatible?
I'm not aware of B2 changes that would affect binary compatibility. Such incompatible changes would be in the Boost jamfiles instead of the B2 tool itself.
Hello! I just updated a PR that we have in ConanCenterIndex CI related to Boost, using ranged version for b2:
b2/[>=5.2 <6]
I'm not aware of B2 changes that would affect binary compatibility. Such incompatible changes would be in the Boost jamfiles instead of the B2 tool itself.
Okay, I'm taking back those words. Turns out there's one possible change only in b2/5.2.0 that may cause binary compat issues.. https://github.com/bfgroup/b2/commit/376470fadd3ecad2b5cf5aa86a261281d479567c#diff-9a030b36fd0e7f9598dc36b4c932695bdf86ea75ae303f1b6d01e63de97d9f95R1935
That change will affect the ABI of the msvc stdlib. This might only be a problem if people disable exception handling with msvc. But I don't see anything in the Boost recipe that would allow for building Boost with exception handling off. But figured I'd point it out just in case. ;-)
Thanks for pointing that out! I have also double-checked the boost recipe, indeed I don't see anything that would allow users to change this, so it seems we are good.
Describe the bug
When attempting to build boost/1.85.0 using an invocation of
conan install ...
in a Windows docker build step (which has access to the latest Visual Studio 2022 build tools at version 17.10) the build fails with the error message: ... boost/1.85.0: ERROR: Package '5b206d5bc0af0b57e57d2785127443f36883ffbb' build failed boost/1.85.0: WARN: Build folder C:\Users\ContainerAdministrator.conan2\p\b\booste815830283dfd\b\build-release ERROR: boost/1.85.0: Error in build() method, line 1130 self.run(full_command) ConanException: Error 1 while executingHow to reproduce it
The docker file is as follows:
The
windows-x86_64-msvc194-release
conan profile that is installed and used is simply:The final failing step in the docker build log is:
It looks to me that the msvc toolset isn't being properly identified by b2 since all of the compiler sanity checks performed by b2 above return no (or none) I suspect it has to do with the b2 issues fixed here (https://github.com/bfgroup/b2/pull/394).
My question is how do I work around this in the short term - until the b2 fix makes its way into the conan boost recipe? Everything is working fine with the Visual Studio 2022 build tools version 17.9.7, but it seems very involved to try to specify a non-latest version of the Visual Studio
vs_buildtools.exe
bootstrapper in my docker file (I am looking into it) and so it seems I am stuck with version 17.10+ (what I get when using the https://aka.ms/vs/17/release/channel and https://aka.ms/vs/17/release/vs_buildtools.exe URLs in the docker file) for now unfortunately. I would think this will affect a good number of users in any case, so should probably be addressed as part of the boost conan recipe anyway (if possible). Unfortunately, it seems b2/5.0.0 is the next release after b2/4.10.1 and that seems to drop backwards compatibility in some way - not sure if that is a problem for building boost or not and not yet sure whether that release contains the necessary patch anyway (I will take a quick look now).Any suggestions gratefully received. Thanks.