Boost Threads Link Problem
Hi, Has all the Boost.Threads problems been solved yet? I am still having link problems with Threads on intel-win32-7.1 -vc6 (w/ or w/out stlport- 4.5.3): http://tinyurl.com/5c2dg Any clues? TIA, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Hi,
Has all the Boost.Threads problems been solved yet? I am still having link problems with Threads on intel-win32-7.1 -vc6 (w/ or w/out stlport- 4.5.3):
Any clues?
TIA,
Most of the Boost.Threads problems have been solved, but not all--though I've been thinking that some of the problems still in the regression testing reports might be due to stale test results. I have been working on some issues today, but this is the first time I've seen the one at the link you posted. In the Spirit regression test that's failing, the library that's being linked with, boost_thread-iw-mt-gdp-1_31.lib, looks like it might be incorrect. If I look at the the Boost.Threads regression tests on intel-win32-7.1, the library it's using is: boost_thread-iw71-mt-gdp-1_31.lib ^^ The name without the version number in the Spirit regression test appears to be generated by auto-link.h. I believe I remember that auto-link should be turned off for regression tests by defining BOOST_ALL_NO_LIB (as it is for Boost.Threads, apparently), though I don't remember why it should be or where the library name comes from in that case. Anyone? Mike
Michael Glassford wrote:
Joel de Guzman wrote:
Hi,
Has all the Boost.Threads problems been solved yet? I am still having link problems with Threads on intel-win32-7.1 -vc6 (w/ or w/out stlport- 4.5.3):
Any clues?
I believe I remember that auto-link should be turned off for regression tests by defining BOOST_ALL_NO_LIB (as it is for Boost.Threads, apparently), though I don't remember why it should be or where the library name comes from in that case. Anyone?
Yes you remember correctly. The reasons are rather simple: if one directly refers to another library in the test, with <dll>* or <lib>*, then the library is linked to directly and hence there is no need for auto-linking. And auto-linking in that case would be redundant, and may even cause errors and warnings from the linker. But the reason one *must* refer to other libraries directly for tests is that auto-linking is not available on all platforms. Hence since they are mutually exclusive and tests need to be cross-platform auto-linking needs to be disabled for regression testing. For the Spirit tests there are two ways to add the correct define: =================================================================== RCS file: /cvsroot/boost/boost/libs/spirit/test/Jamfile,v retrieving revision 1.23 diff -u -r1.23 Jamfile --- Jamfile 20 Jul 2004 00:48:28 -0000 1.23 +++ Jamfile 28 Jul 2004 04:32:16 -0000 @@ -73,6 +73,7 @@ #template multi-threading : <dll>../../thread/build/boost_thread : : template multi-threading : <dll>@boost/libs/thread/build/boost_thread : : <threading>multi + <define>BOOST_ALL_NO_LIB=1 $(spirit-header-include) ; } =================================================================== Or: =================================================================== RCS file: /cvsroot/boost/boost/libs/spirit/test/Jamfile,v retrieving revision 1.23 diff -u -r1.23 Jamfile --- Jamfile 20 Jul 2004 00:48:28 -0000 1.23 +++ Jamfile 28 Jul 2004 04:34:02 -0000 @@ -38,13 +38,13 @@ SEARCH on $(input-files) = $(SEARCH_SOURCE) ; name ?= $(sources[1]:D=:S=) ; name = $(name)_debug ; - return [ boost-test $(sources) : RUN : $(requirements) <define>BOOST_SPIRIT_DEBUG=1 : $(name) : $(default-build) ] ; + return [ boost-test $(sources) : RUN : $(requirements) <define>BOOST_SPIRIT_DEBUG=1 <define>BOOST_ALL_NO_LIB=1 : $(name) : $(default-build) ] ; } rule spirit-run ( sources + : args * : input-files * : requirements * : name ? : default-build * ) { run $(sources) : $(args) : $(input-files) : $(requirements) : $(name) : $(default-build) ; - spirit-run-debug $(sources) : $(args) : $(input-files) : $(requirements) : $(name) : $(default-build) ; + spirit-run-debug $(sources) : $(args) : $(input-files) : $(requirements) <define>BOOST_ALL_NO_LIB=1 : $(name) : $(default-build) ; } ############################################################ =================================================================== The first one has the benefit that the extra define is *only* added when the thread library is used. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
Michael Glassford wrote:
Joel de Guzman wrote:
Hi,
Has all the Boost.Threads problems been solved yet? I am still having link problems with Threads on intel-win32-7.1 -vc6 (w/ or w/out stlport- 4.5.3):
Any clues?
I believe I remember that auto-link should be turned off for regression tests by defining BOOST_ALL_NO_LIB (as it is for Boost.Threads, apparently), though I don't remember why it should be or where the library name comes from in that case. Anyone?
Yes you remember correctly. The reasons are rather simple: if one directly refers to another library in the test, with <dll>* or <lib>*, then the library is linked to directly and hence there is no need for auto-linking. And auto-linking in that case would be redundant, and may even cause errors and warnings from the linker. But the reason one *must* refer to other libraries directly for tests is that auto-linking is not available on all platforms. Hence since they are mutually exclusive and tests need to be cross-platform auto-linking needs to be disabled for regression testing.
For the Spirit tests there are two ways to add the correct define:
[...]
The first one has the benefit that the extra define is *only* added when the thread library is used.
Thanks! I applied the first simpler patch. I hope to see everything green tomorrow. Fingers crossed... Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Yes you remember correctly. The reasons are rather simple: if one directly refers to another library in the test, with <dll>* or <lib>*, then the library is linked to directly and hence there is no need for auto-linking. And auto-linking in that case would be redundant, and may even cause errors and warnings from the linker. But the reason one *must* refer to other libraries directly for tests is that auto-linking is not available on all platforms. Hence since they are mutually exclusive and tests need to be cross-platform auto-linking needs to be disabled for regression testing.
They're not mutually exclusive as long as the toolsets are consistently named so that the auto-link code can always generate the same name as the toolset for the library. Unfortunately the toolsets (mainly the Intel ones) aren't consistently named - we have the main toolset with no version number, for which the autolink code does the right thing, and a bunch of other versioned toolsets for which it does not :-( John.
Joel de Guzman wrote:
Rene Rivera wrote:
For the Spirit tests there are two ways to add the correct define:
[...]
The first one has the benefit that the extra define is *only* added when the thread library is used.
Thanks! I applied the first simpler patch. I hope to see everything green tomorrow. Fingers crossed...
Hi, Ok, that worked very well. Yet, there are still some boost.threads quirks. 1) On Comeau, it seems that boost threads is disabled. Is this correct? <http://tinyurl.com/5sgn8>. If so, should we disable the tests that involve threads on Comeau? Or, at least note the problem in the reports? If so, could anyone point me to the reason why it is disabled? 2) On VC8.0, I am again having a link problem: LINK : fatal error LNK1181: cannot open input file 'boost_thread-vc8.lib' Does anyone have a clue how to fix this? <http://tinyurl.com/3jmem> TIA, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
2) On VC8.0, I am again having a link problem: LINK : fatal error LNK1181: cannot open input file 'boost_thread-vc8.lib' Does anyone have a clue how to fix this? <http://tinyurl.com/3jmem>
I think I just fixed that. The Boost.Build common variant tag code was not accounting for the new toolset name. File changed: tools/build/boost-base.jam -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
Joel de Guzman wrote:
2) On VC8.0, I am again having a link problem: LINK : fatal error LNK1181: cannot open input file 'boost_thread-vc8.lib' Does anyone have a clue how to fix this? <http://tinyurl.com/3jmem>
I think I just fixed that. The Boost.Build common variant tag code was not accounting for the new toolset name.
File changed: tools/build/boost-base.jam
Oops, that should be tools/build/v1/boost-base.jam :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
Rene Rivera wrote:
Joel de Guzman wrote:
2) On VC8.0, I am again having a link problem: LINK : fatal error LNK1181: cannot open input file 'boost_thread-vc8.lib' Does anyone have a clue how to fix this? <http://tinyurl.com/3jmem>
I think I just fixed that. The Boost.Build common variant tag code was not accounting for the new toolset name.
File changed: tools/build/boost-base.jam
Oops, that should be tools/build/v1/boost-base.jam
The regression test is dated: Thu, 29 Jul 2004 17:53:19 +0000 Perhaps I should just wait? Thanks, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
At Thursday 2004-07-29 20:42, you wrote:
Rene Rivera wrote:
Rene Rivera wrote:
Joel de Guzman wrote:
2) On VC8.0, I am again having a link problem: LINK : fatal error LNK1181: cannot open input file 'boost_thread-vc8.lib' Does anyone have a clue how to fix this? <http://tinyurl.com/3jmem>
I think I just fixed that. The Boost.Build common variant tag code was not accounting for the new toolset name.
File changed: tools/build/boost-base.jam
Oops, that should be tools/build/v1/boost-base.jam
The regression test is dated: Thu, 29 Jul 2004 17:53:19 +0000 Perhaps I should just wait?
I'll start mine again (hopefully it won't take 6 hours this time)
Thanks, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Joel de Guzman wrote:
Rene Rivera wrote:
Rene Rivera wrote:
Joel de Guzman wrote:
2) On VC8.0, I am again having a link problem: LINK : fatal error LNK1181: cannot open input file 'boost_thread-vc8.lib' Does anyone have a clue how to fix this? <http://tinyurl.com/3jmem>
I think I just fixed that. The Boost.Build common variant tag code was not accounting for the new toolset name.
Yep, that seems to have fixed it :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
In the Spirit regression test that's failing, the library that's being linked with, boost_thread-iw-mt-gdp-1_31.lib, looks like it might be incorrect. If I look at the the Boost.Threads regression tests on intel-win32-7.1, the library it's using is:
boost_thread-iw71-mt-gdp-1_31.lib ^^ The name without the version number in the Spirit regression test appears to be generated by auto-link.h. I believe I remember that auto-link should be turned off for regression tests by defining BOOST_ALL_NO_LIB (as it is for Boost.Threads, apparently), though I don't remember why it should be or where the library name comes from in that case. Anyone?
Sadly you have to turn it off if your using a toolset that produces a different name from the auto-link header - generally this is an Intel toolset problem, where we have both "versioned" and "unversioned" toolset names. The autolink header can do one or the other but not both (it's not psychic!), we really need some consistency here, but no one seems to be interested in systematising the toolset names :-( John.
participants (1)
-
Joel de Guzman -
John Maddock -
Michael Glassford -
Rene Rivera -
Victor A. Wagner Jr.