The error message in http://tinyurl.com/6ynh9 says that some symbols are multiply declared. The error messages refer to Boost.Test, and also some compiler library, and is hard to understand. Could any expert take a look? - Volodya
On Thu, 26 Aug 2004 14:02:00 +0400 Vladimir Prus <ghost@cs.msu.su> wrote:
The error message in
says that some symbols are multiply declared. The error messages refer to Boost.Test, and also some compiler library, and is hard to understand.
There was a similar error within the thread tests. Suggestion: Have a look into the cmdline_test.CMD file, which is beeing fed to the linker. Could it be that single threaded and multi-threaded versions are beeing linked together? Roland
Roland wrote:
On Thu, 26 Aug 2004 14:02:00 +0400 Vladimir Prus <ghost@cs.msu.su> wrote:
The error message in
says that some symbols are multiply declared. The error messages refer to Boost.Test, and also some compiler library, and is hard to understand.
There was a similar error within the thread tests. Suggestion: Have a look into the cmdline_test.CMD file, which is beeing fed to the linker.
Unfortunately, I don't have that compiler around, so it's hard to look at the file.
Could it be that single threaded and multi-threaded versions are beeing linked together?
I don't know. The test Jamfile does not force either single or multi threading. I note howerver, that only statically linked tests fail, and statically linked test have "std::facet-support" in requirements, which, in turn, force static runtime on intel. I'll try to remove that requirement and see if it fixes the situation. - Volodya
Roland
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Thu, 26 Aug 2004 14:34:30 +0400 Vladimir Prus <ghost@cs.msu.su> wrote:
Unfortunately, I don't have that compiler around, so it's hard to look at the file.
Could it be that single threaded and multi-threaded versions are beeing linked together?
I don't know. The test Jamfile does not force either single or multi threading. I note howerver, that only statically linked tests fail, and statically linked test have "std::facet-support" in requirements, which, in turn, force static runtime on intel. I'll try to remove that requirement and see if it fixes the situation.
I quote a message from Michael Glassford:
Bronek Kozicki says he has tracked down the problem for me: adding "<threading>multi" to boost_thread_lib_base and boost_thread_dll_base in libs\boost\thread\build\jamfile fixes the problem.
To be honest, I know not enough about bjam, but perhaps you could ask Bronek Kozicki? Roland
Roland wrote:
On Thu, 26 Aug 2004 14:34:30 +0400 Vladimir Prus <ghost@cs.msu.su> wrote:
Unfortunately, I don't have that compiler around, so it's hard to look at the file.
Could it be that single threaded and multi-threaded versions are beeing linked together?
I don't know. The test Jamfile does not force either single or multi threading. I note howerver, that only statically linked tests fail, and statically linked test have "std::facet-support" in requirements, which, in turn, force static runtime on intel. I'll try to remove that requirement and see if it fixes the situation.
I quote a message from Michael Glassford:
Bronek Kozicki says he has tracked down the problem for me: adding "<threading>multi" to boost_thread_lib_base and boost_thread_dll_base in libs\boost\thread\build\jamfile fixes the problem.
To be honest, I know not enough about bjam, but perhaps you could ask Bronek Kozicki?
I'm also not a bjam expert, and Bronek said he wasn't either. He arrived at this solution by experimentation. Roland's right, though: the error message looks identical to the Boost.Threads error that was fixed by this change. It would be nice if someone got to the root of the problem and figured out what change caused this error: it only appeared recently, at a time when no Boost.Threads changes had been made. Mike
Hi All,
I quote a message from Michael Glassford:
Bronek Kozicki says he has tracked down the problem for me: adding "<threading>multi" to boost_thread_lib_base and boost_thread_dll_base in libs\boost\thread\build\jamfile fixes the problem.
To be honest, I know not enough about bjam, but perhaps you could ask Bronek Kozicki?
I'm also not a bjam expert, and Bronek said he wasn't either. He arrived at this solution by experimentation.
Roland's right, though: the error message looks identical to the Boost.Threads error that was fixed by this change. It would be nice if someone got to the root of the problem and figured out what change caused this error: it only appeared recently, at a time when no Boost.Threads changes had been made.
With all those replies, I was able to diagnose the problem. On a number of toolsets, <runtime-link>dynamic automatically sets <threading>multi. The program_options jamfiles had std::facet-support in requirements, which forces <runtime-link>static on intel. Apparently, the handling of std::facet-support is done after <threading>multi is added, which leads to inconsistency. I'll raise the issue on jamboost@ Thanks! - Volodya
Roland's right, though: the error message looks identical to the Boost.Threads error that was fixed by this change. It would be nice if someone got to the root of the problem and figured out what change caused this error: it only appeared recently, at a time when no Boost.Threads changes had been made.
With all those replies, I was able to diagnose the problem. On a number of toolsets, <runtime-link>dynamic automatically sets <threading>multi. The program_options jamfiles had std::facet-support in requirements, which forces <runtime-link>static on intel. Apparently, the handling of std::facet-support is done after <threading>multi is added, which leads to inconsistency.
I'll raise the issue on jamboost@
BTW isn't the std::facet-support option irrelevant now? It only has any effect for Intel (last time I looked), and since Intel have long since fixed the bugs that caused us to add that option, can't we just get rid of it? John.
John Maddock wrote:
With all those replies, I was able to diagnose the problem. On a number of toolsets, <runtime-link>dynamic automatically sets <threading>multi. The program_options jamfiles had std::facet-support in requirements, which forces <runtime-link>static on intel. Apparently, the handling of std::facet-support is done after <threading>multi is added, which leads to inconsistency.
I'll raise the issue on jamboost@
BTW isn't the std::facet-support option irrelevant now? It only has any effect for Intel (last time I looked), and since Intel have long since fixed the bugs that caused us to add that option, can't we just get rid of it?
Yea, I recall you mentioned that before, that's why I've removed std::facet-support from Jamfile and is now waiting for next regression tests run for see if that fixes the problem. - Volodya
Vladimir Prus wrote:
With all those replies, I was able to diagnose the problem. On a number of toolsets, <runtime-link>dynamic automatically sets <threading>multi. The
In toolsets from MSVC family (msvc, vc7, vc7.1 and vc8) it actualy makes sense, as in Visual C++ dynamic CRT is always multithreaded; there's no "dynamically linked single threaded CRT". I suppose that this might be true for number of other compilers on this platform, too. B.
Roland wrote:
On Thu, 26 Aug 2004 14:34:30 +0400 Vladimir Prus <ghost@cs.msu.su> wrote:
Bronek Kozicki says he has tracked down the problem for me: adding "<threading>multi" to boost_thread_lib_base and boost_thread_dll_base in libs\boost\thread\build\jamfile fixes the problem.
To be honest, I know not enough about bjam, but perhaps you could ask Bronek Kozicki?
I do not know bjam neither, just playing a little with libs\thread\test\Jamfile seemed to fix problem with Boost.Threads tests. However looking at the http://tinyurl.com/6ynh9 I can see something similar to problem with Boost.Threads (besides list of familiar error messages). Take a look at list of arguments passed to xilink : /LIBPATH:"...\program_options\build\libboost_program_options.lib\intel-win32-8.0\debug\runtime-link-static\threading-multi" /LIBPATH:"...\test\build\libboost_test_exec_monitor.lib\intel-win32-8.0\debug\runtime-link-static" Apparently "libboost_test_exec_monitor.lib" being linked is singlethreaded, while "libboost_program_options.lib" is multithreaded. This reasults in two different versions of static CRT being brought into single excutable, thus error. Sincerly, when looking at boost\libs\program_options\test\Jamfile I have no idea how to update it (as I do not know bjam), and I do not have Intel compiler to play with it. If anyone knows bjam well enough and/or has Intel compiler, I would suggest seeking for a way to force linking with multithreaded version of libboost_test_exec_monitor.lib, instead of singlethreaded one. B.
Bronek Kozicki <brok@rubikon.pl> wrote:
Apparently "libboost_test_exec_monitor.lib" being linked is singlethreaded, while "libboost_program_options.lib" is
multithreaded.
This reasults in two different versions of static CRT being brought into single excutable, thus error.
Hi all, I've reported this problem a week ago but I didn't have enough time to fix it (the problem is definitely that there are two runtime libraries linked together). I'm currently on vacation and my access to the web is restricted to internet cafes. I'll look into it when I'm back next week (however, I'm no bjam expert either). Stefan
Looks like Boost.Test library was build with different (from the test program) version of runtime. Gennadiy. "Vladimir Prus" <ghost@cs.msu.su> wrote in message news:200408261402.00046.ghost@cs.msu.su...
The error message in
says that some symbols are multiply declared. The error messages refer to Boost.Test, and also some compiler library, and is hard to understand.
Could any expert take a look?
- Volodya
participants (2)
-
Bronek Kozicki -
Gennadiy Rozental -
John Maddock -
Michael Glassford -
Roland -
Stefan Slapeta -
Vladimir Prus