b2 --layout=versioned compiler tag in library filename
Hi guys, In the past, b2 would build libraries named like so: libboost_atomic-gcc48-mt-d-1_60.so (note -gcc48-) I tried compiling Boost 1.66.0 (from boost-git) with gcc 8.3.0, but the library it generates is named: libboost_atomic-gcc-mt-d-x64-1_66.so (note the -gcc-) No compiler version number in the tag... I (and CMake) was expecting it to be named: libboost_atomic-gcc83-mt-d-x64-1_66.so (note the -gcc83-) To build, I did: ./bootstrap.sh --with-libraries="atomic" ./b2 --layout=versioned I then downloaded the 1.70.0 tarball and compiled that, and this time the result was: tar xfv boost_1_70_0.tar.bz2 cd boost_1_70_0/ ./bootstrap.sh --with-libraries="atomic" ./b2 --layout=versioned ls -l stage/lib libboost_atomic-gcc8-mt-d-x64-1_70.so I don't see any documentation around the compiler version tag, what is the current policy? thanks, Paul
On Tue, 30 Apr 2019 at 15:54, Paul Harris via Boost
Possibly, it's related to the change in GCC 5+ versioning. This was accommodated in Boost.Build in October 2018 https://github.com/boostorg/build/pull/349 that is, in Boost 1.69 (boostorg/build should use milestones for issues, IMO) BTW, there are also CMake's issues in FindCMake.cmake related to the compiler and architecture tag. So, you may have to specify Boost_COMPILER and Boost_ARCHITECTURE hints in order to help FindBoost.cmake recognise versioned names.
I don't see any documentation around the compiler version tag, what is the current policy?
One of is what b2 --help says about --layout "The default value is 'versioned' on Windows, and 'system' on Unix." Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On Tue, 30 Apr 2019 at 22:53, Mateusz Loskot via Boost < boost@lists.boost.org> wrote:
Excellent, thanks for that reference.
Seems like something that could be fixed at the CMake end... is anyone working on that?
Yes but it doesn't mention anything about the compiler version tag and how the version number is decided (and how that decision changed). and the new x64 tag. or any of the tags. https://www.boost.org/doc/libs/1_70_0/more/getting_started/unix-variants.htm... this just says -vc71 Toolset tag: identifies the toolset and version used to build the binary. I would've liked to see a little more detail on the "version" part, in particular, how it changed with a particular Boost and Compiler version. Thanks again! Paul
On Wed, 1 May 2019 at 02:10, Paul Harris
Things are being fixed, for example https://gitlab.kitware.com/cmake/cmake/merge_requests/2579 Another fix related to your problem was this https://gitlab.kitware.com/cmake/cmake/issues/17701 which actually spawned introduction of Boost_ARCHITECTURE https://gitlab.kitware.com/cmake/cmake/merge_requests/2568 Those hints like Boost_ARCHITECTURE, Boost_COMPILER are actually provided to let users work around FindBoost.cmake deficiencies. Since Find-modules are just 'guessers', they (and maintainers) are doing their best, but they will never be solid and change-proof.
No idea, but reading and blaming the source code itself may help, e.g.: https://github.com/boostorg/build/blob/develop/src/tools/common.jam#L960-L10...
AFAIK, it's always compiler's major and minor version stitched together. Then, for GCC this scheme had to change to major only bacause: "From GCC 5, versioning changes and minor becomes patch" Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
AMDG On 4/30/19 7:08 PM, Peter Dimov via Boost wrote:
The order events was something like this: original: Boost.Build originally uses gcc48, for example. - gcc -dumpversion only returns the major version. This no longer matches the regex in common.jam, causing the version in the library name to be blank. - Boost.Build is adjusted to use -dumpfullversion instead, restoring the original library naming. - Boost.Build is adjusted to include only the major version in the library name (the change Mateusz mentioned). In Christ, Steven Watanabe
On 1/05/2019 13:08, Peter Dimov wrote:
I don't think it's possible for a change in 1.69 to affect how 1.66 is built. Something else must be wrong.
I think the point was that newer GCC changed how the version was reported. 1.69 knows about that change and accommodates it, while 1.66 doesn't, and breaks. So either using newer Boost or older GCC is required.
participants (5)
-
Gavin Lambert -
Mateusz Loskot -
Paul Harris -
Peter Dimov -
Steven Watanabe