b2 --layout=versioned compiler tag in library filename

older
[thread] compiler error gcc 7.3 on...

Paul Harris

30 Apr 2019 30 Apr '19

1:54 p.m.

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

Show replies by date

Mateusz Loskot

30 Apr 30 Apr

2:52 p.m.

On Tue, 30 Apr 2019 at 15:54, Paul Harris via Boost wrote:

...

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...

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

Paul Harris

1 May 1 May

12:10 a.m.

On Tue, 30 Apr 2019 at 22:53, Mateusz Loskot via Boost < boost@lists.boost.org> wrote:

...

On Tue, 30 Apr 2019 at 15:54, Paul Harris via Boost wrote:

...
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...

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)

Excellent, thanks for that reference.

...

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.

Seems like something that could be fixed at the CMake end... is anyone working on that?

...

...
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."

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

Mateusz Loskot

12:45 a.m.

On Wed, 1 May 2019 at 02:10, Paul Harris wrote:

...

On Tue, 30 Apr 2019 at 22:53, Mateusz Loskot via Boost wrote:

...
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.

Seems like something that could be fixed at the CMake end... is anyone working on that?

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.

...

...
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."

Yes but it doesn't mention anything about the compiler version tag and how the version number is decided (and how that decision changed).

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...

...

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.

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

Peter Dimov

1:08 a.m.

Paul Harris wrote:

...

On Tue, 30 Apr 2019 at 22:53, Mateusz Loskot via Boost < boost@lists.boost.org> wrote:

...
On Tue, 30 Apr 2019 at 15:54, Paul Harris via Boost wrote:

...
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...

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)

Excellent, thanks for that reference.

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.

Steven Watanabe

1:23 a.m.

AMDG On 4/30/19 7:08 PM, Peter Dimov via Boost wrote:

...

Paul Harris wrote:

...
On Tue, 30 Apr 2019 at 22:53, Mateusz Loskot via Boost < boost@lists.boost.org> wrote:

...
On Tue, 30 Apr 2019 at 15:54, Paul Harris via Boost wrote:

...
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...

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)

Excellent, thanks for that reference.

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.

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

Paul Harris

7:31 a.m.

On Wed, 1 May 2019 at 09:23, Steven Watanabe via Boost < boost@lists.boost.org> wrote:

...

AMDG

On 4/30/19 7:08 PM, Peter Dimov via Boost wrote:

...
Paul Harris wrote:

...
On Tue, 30 Apr 2019 at 22:53, Mateusz Loskot via Boost < boost@lists.boost.org> wrote:

...
On Tue, 30 Apr 2019 at 15:54, Paul Harris via Boost wrote:

...
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...

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)

Excellent, thanks for that reference.

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 agree, but I will work around it for now, and look forward to upgrading myself to 1.70+ Unless someone wants me to help debug it. Thanks very much for helping me to understand :) Paul

Gavin Lambert

6 May 6 May

7:12 a.m.

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.

2031

Age (days ago)

2037

Last active (days ago)

List overview

Download

7 comments

5 participants

participants (5)

Gavin Lambert
Mateusz Loskot
Paul Harris
Peter Dimov
Steven Watanabe