[1.34] autolink doesn't work when not specifying toolset version
I downloaded 1.34.0 beta, compiled it using bjam --toolset=msvc --without-python stage then wrote a small program that uses Boost.Thread. It didn't link. The linker was looking for libboost_thread-vc80-mt-gd-1_34.lib, but couldn't find it. Rightfully enough, because there was no such file. The bjam command created libboost_thread-vc-mt-gd-1_34.lib - almost the same, just "vc" instead of "vc80". So I ran bjam again, this time with bjam --toolset=msvc-8.0 --without-python stage and then everything worked fine. This can a be a bug either in Boost.Build, or in the autolink feature, or in the documentation (getting_started.html) that suggests that specifying the toolset version is optional, or in my brain... Which is it?
Yuval Ronen wrote:
I downloaded 1.34.0 beta, compiled it using
bjam --toolset=msvc --without-python stage
then wrote a small program that uses Boost.Thread. It didn't link. The linker was looking for libboost_thread-vc80-mt-gd-1_34.lib, but couldn't find it. Rightfully enough, because there was no such file. The bjam command created libboost_thread-vc-mt-gd-1_34.lib - almost the same, just "vc" instead of "vc80".
So I ran bjam again, this time with
bjam --toolset=msvc-8.0 --without-python stage
and then everything worked fine.
This can a be a bug either in Boost.Build, or in the autolink feature, or in the documentation (getting_started.html) that suggests that specifying the toolset version is optional, or in my brain... Which is it?
The way I view it is that in 1.33.1, you'd specify vc_8_0 as toolset, and in 1.34 you have to specify msvc-8.0 to achieve same effect. The behaviour with plain "msvc" may be a bug, or feature, or doc issue, depending on your point of view. - Volodya
Vladimir Prus wrote:
Yuval Ronen wrote:
I downloaded 1.34.0 beta, compiled it using
bjam --toolset=msvc --without-python stage
then wrote a small program that uses Boost.Thread. It didn't link. The linker was looking for libboost_thread-vc80-mt-gd-1_34.lib, but couldn't find it. Rightfully enough, because there was no such file. The bjam command created libboost_thread-vc-mt-gd-1_34.lib - almost the same, just "vc" instead of "vc80".
So I ran bjam again, this time with
bjam --toolset=msvc-8.0 --without-python stage
and then everything worked fine.
This can a be a bug either in Boost.Build, or in the autolink feature, or in the documentation (getting_started.html) that suggests that specifying the toolset version is optional, or in my brain... Which is it?
The way I view it is that in 1.33.1, you'd specify vc_8_0 as toolset, and in 1.34 you have to specify msvc-8.0 to achieve same effect. The behaviour with plain "msvc" may be a bug, or feature, or doc issue, depending on your point of view.
So what's your point of view? Anyone else? As a Boost user, my point of view that if the docs says I can use plain "msvc" and use autolink, but in fact I can't, then it's certainly a bug. Whether it's a doc bug, or a different bug, is up to the Boost developers to decide. I personally don't have any opinion on this. All I know is that the docs don't match the status in the real life.
Yuval Ronen wrote:
The way I view it is that in 1.33.1, you'd specify vc_8_0 as toolset, and in 1.34 you have to specify msvc-8.0 to achieve same effect. The behaviour with plain "msvc" may be a bug, or feature, or doc issue, depending on your point of view.
So what's your point of view? Anyone else?
As a Boost user, my point of view that if the docs says I can use plain "msvc" and use autolink,
Where does it say that? If that's the case, that's doc bug. - Volodya
Vladimir Prus wrote:
Yuval Ronen wrote:
The way I view it is that in 1.33.1, you'd specify vc_8_0 as toolset, and in 1.34 you have to specify msvc-8.0 to achieve same effect. The behaviour with plain "msvc" may be a bug, or feature, or doc issue, depending on your point of view. So what's your point of view? Anyone else?
As a Boost user, my point of view that if the docs says I can use plain "msvc" and use autolink,
Where does it say that? If that's the case, that's doc bug.
In /more/getting_started/windows.html in the Boost 1.34.0 beta package. Specifically look at section 5.2.4 and section 6.
on Sat May 05 2007, Yuval Ronen
Vladimir Prus wrote:
Yuval Ronen wrote:
The way I view it is that in 1.33.1, you'd specify vc_8_0 as toolset, and in 1.34 you have to specify msvc-8.0 to achieve same effect. The behaviour with plain "msvc" may be a bug, or feature, or doc issue, depending on your point of view. So what's your point of view? Anyone else?
As a Boost user, my point of view that if the docs says I can use plain "msvc" and use autolink,
Where does it say that? If that's the case, that's doc bug.
In /more/getting_started/windows.html in the Boost 1.34.0 beta package. Specifically look at section 5.2.4 and section 6.
Well, if it's not a Boost.Build / BoostAutolink bug, it's certainly surprising. In one context, boost code automatically detects the msvc version and forces a request to a library whose name contains that version number, and in another context, boost code generates a complicated library name, ignoring the version number, that can **never** be linked to by any Boost code unless autolinking is disabled. This should **just work**, and it's possible (probably easy) to implement. Sorry, I just can't accept that it's the fault of the documentation. -- Dave Abrahams Boost Consulting www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
David Abrahams wrote:
on Sat May 05 2007, Yuval Ronen
wrote: Vladimir Prus wrote:
Yuval Ronen wrote:
The way I view it is that in 1.33.1, you'd specify vc_8_0 as toolset, and in 1.34 you have to specify msvc-8.0 to achieve same effect. The behaviour with plain "msvc" may be a bug, or feature, or doc issue, depending on your point of view. So what's your point of view? Anyone else?
As a Boost user, my point of view that if the docs says I can use plain "msvc" and use autolink, Where does it say that? If that's the case, that's doc bug. In /more/getting_started/windows.html in the Boost 1.34.0 beta package. Specifically look at section 5.2.4 and section 6.
This should **just work**, and it's possible (probably easy) to implement. Sorry, I just can't accept that it's the fault of the documentation.
Especially given that "--toolset=gcc" behaves as expected by users, i.e. as if one had done "--toolset=gcc-x.y". -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
David Abrahams wrote:
As a Boost user, my point of view that if the docs says I can use plain "msvc" and use autolink,
Where does it say that? If that's the case, that's doc bug.
In /more/getting_started/windows.html in the Boost 1.34.0 beta package. Specifically look at section 5.2.4 and section 6.
Well, if it's not a Boost.Build / BoostAutolink bug, it's certainly surprising. In one context, boost code automatically detects the msvc version and forces a request to a library whose name contains that version number, and in another context, boost code generates a complicated library name, ignoring the version number, that can **never** be linked to by any Boost code unless autolinking is disabled. This should **just work**, and it's possible (probably easy) to implement. Sorry, I just can't accept that it's the fault of the documentation.
I don't think there's anything that autolinking can do to fix this: it requires that libraries are named consistently, and there's no way around that. So we either need to update the docs, or preferably fix Boost.Build to detect the MSVC version. As Dave says it does this in other contexts already, so it should be possible. BTW, this is a showstopper for 1.34 release I believe. John.
John Maddock wrote:
David Abrahams wrote:
As a Boost user, my point of view that if the docs says I can use plain "msvc" and use autolink, Where does it say that? If that's the case, that's doc bug. In /more/getting_started/windows.html in the Boost 1.34.0 beta package. Specifically look at section 5.2.4 and section 6. Well, if it's not a Boost.Build / BoostAutolink bug, it's certainly surprising. In one context, boost code automatically detects the msvc version and forces a request to a library whose name contains that version number, and in another context, boost code generates a complicated library name, ignoring the version number, that can **never** be linked to by any Boost code unless autolinking is disabled. This should **just work**, and it's possible (probably easy) to implement. Sorry, I just can't accept that it's the fault of the documentation.
I don't think there's anything that autolinking can do to fix this: it requires that libraries are named consistently, and there's no way around that.
So we either need to update the docs, or preferably fix Boost.Build to detect the MSVC version. As Dave says it does this in other contexts already, so it should be possible.
Given the hint that the version number in the tool specification was important I managed to get the right build output names using --tools=msvc-7.1 (took me a couple of tries to work out the right tool name to use). Personally I think a documentation change (clarification?) is enough if it's the only thing holding up the release. It would be perfect if it could do this without the tool specification *and* it could hide warnings that clearly aren't of concern to the libs involved (C4511 no copy constructor can be made - seems to be one). If it is only a matter of getting different output libraries then I can't see that it really helps that much from a presentation point of view. The same benefit can be had from just telling people which --tools command to use and the default I guess works without auto-linking. K
on Sun May 06 2007, "John Maddock"
I don't think there's anything that autolinking can do to fix this: it requires that libraries are named consistently, and there's no way around that.
Yes, that's not what I meant to imply.
So we either need to update the docs, or preferably fix Boost.Build to detect the MSVC version. As Dave says it does this in other contexts already, so it should be possible.
Exactly.
BTW, this is a showstopper for 1.34 release I believe.
Absolutely. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
participants (6)
-
David Abrahams -
John Maddock -
Kirit Sælensminde -
Rene Rivera -
Vladimir Prus -
Yuval Ronen