Hi all, I'm starting to use boost for the first time now, but I'm having problems linking to the thread library (libboost_thread.lib) from within Visual C++. Using my main compiler, VC++ 6.0, I get the following linker error: libboost_thread.lib(exceptions.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::basic_string<char,struct std::char_traits<ch ar>,class std::allocator<char> >(char const *)" I checked the compiler compatibility tables online at the boost site, but they're not recent enough to include any details on the thread library. When I use Visual C++ .NET (feel free to shrink away in horror) to test it, I get about 8 linker errors complaining that a handful of standard library functions (most dealing with the basic_string and exception classes) are being redefined by libboost_thread.lib. Does anybody have any experience with this or ideas on what I could be doing wrong? I'm just starting to do multi-platform software design, and boost::thread would be a godsend! Thanks, Jonathan
cadenzajon wrote:
Hi all, ...
Using my main compiler, VC++ 6.0, I get the following linker error: libboost_thread.lib(exceptions.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::basic_string<char,struct std::char_traits<ch ar>,class std::allocator<char> >(char const *)" ... Does anybody have any experience with this or ideas on what I could be doing wrong? I'm just starting to do multi-platform software design, and boost::thread would be a godsend!
Thanks,
Jonathan
We have recently started to use boost in Windows and we have had a similar problem. After some tries, we have sucesfully made a Multithreaded Console Application doing this: In C/C++ -> Code Generation -> Use run-time library select Debug Multithreaded DLL In C/C++ -> C++ Language select Enable RTTI In Link -> Input -> Object/Library modules clean all the entries (leave it blank) In Link -> Input -> Ignore Libraries set: libcmtd.lib, libcmt.lib, libcd.lib, libc.lib In the "Source Files" folder of the File View add libboost_thread.lib. We have never tried to do something else than a "Multithreaded Console Application". By the way, the conditional variables doesn't seems to work in the 1.26.0 version of the library. We are using pthreads and boost to make our programs. Hope you find this useful. -- Raúl Huertas Díaz Redes y Comunicaciones Ingeniero de Sistemas TCP Sistemas e Ingenieria Fernández Caro, 7, 3ª planta Tel.: +34 91 367 32 79 (Ext. 535) Fax: +34 91 407 71 39 rhuertas@tcpsi.es http://www.tcpsi.es [Non-text portions of this message have been removed]
--- In Boost-Users@y..., Raul Huertas <rhuertas@t...> wrote:
We have recently started to use boost in Windows and we have had a similar problem. After some tries, we have sucesfully made a Multithreaded Console Application doing this:
In C/C++ -> Code Generation -> Use run-time library select Debug Multithreaded DLL
I'm 99% sure this was the only problem.
In C/C++ -> C++ Language select Enable RTTI
A good idea in general.
In Link -> Input -> Object/Library modules clean all the entries (leave it blank)
This shouldn't be necessary.
In Link -> Input -> Ignore Libraries set: libcmtd.lib, libcmt.lib, libcd.lib, libc.lib
In the "Source Files" folder of the File View add
I'm also not sure that this should be necessary. libboost_thread.lib.
We have never tried to do something else than a "Multithreaded
Console
Application".
Should be no different.
By the way, the conditional variables doesn't seems to work in the 1.26.0 version of the library. We are using pthreads and boost to make our programs.
The examples and test harness work fine. However, there was a bug that would cause occasional deadlock when calling notify_one() under certain conditions. This has been fixed and is in the CVS repository now. Bill Kempf
Thank you all for your prompt responses. I comment further below:
We have recently started to use boost in Windows and we have had a similar problem. After some tries, we have sucesfully made a Multithreaded Console Application doing this:
In C/C++ -> Code Generation -> Use run-time library select Debug Multithreaded DLL
I'm 99% sure this was the only problem.
I already was using the multithreaded libraries. If I had select single-threaded libraries, the boost::thread hpp files would have generated a compiler error.
In C/C++ -> C++ Language select Enable RTTI
A good idea in general.
I had already enabled RTTI.
In Link -> Input -> Object/Library modules clean all the entries (leave it blank)
This shouldn't be necessary.
This was already blank.
In Link -> Input -> Ignore Libraries set: libcmtd.lib, libcmt.lib, libcd.lib, libc.lib
I'm also not sure that this should be necessary.
This was interesting. On Visual C++ 6.0, it did not make any difference to the linker output. On Visual C++ .NET, it removed all the 'multiply defined symbol' errors except for those relating to three basic_string constructors and basic_string::c_str(). (It solved MOST of the problem, but didn't take care of everything.) However, if I exclude the main C runtime library files from my build as you suggest, it seems like I would run into more problems later on when I try to use standard C functions. Again, my problem when linking with the library in VC6 is that libboost_thread.lib(exceptions.obj) has one unresolved external symbol for basic_string::basic_string(char const *). I'm still flummoxed. If you have more ideas, I would really appreciate them. Thanks, Jonathan
--- In Boost-Users@y..., "Jonathan Brownell" <alphaomega@p...> wrote:
Thank you all for your prompt responses. I comment further below:
We have recently started to use boost in Windows and we have had a similar problem. After some tries, we have sucesfully made a Multithreaded Console Application doing this:
In C/C++ -> Code Generation -> Use run-time library select Debug Multithreaded DLL
I'm 99% sure this was the only problem.
I already was using the multithreaded libraries. If I had select single-threaded libraries, the boost::thread hpp files would have generated a compiler error.
The key to what I said was _DLL_. There are two multi-threaded libraries, a LIB and a DLL version.
I'm still flummoxed. If you have more ideas, I would really appreciate them.
Insure you're linking against the multithreaded _DLL_ version of the run-time library. If you still have problems Zip up a small example project that's giving you problems and e-mail it to me. Bill Kempf
* Jonathan Brownell (alphaomega@proaxis.com) wrote:
Thank you all for your prompt responses. I comment further below:
[snip]
Again, my problem when linking with the library in VC6 is that libboost_thread.lib(exceptions.obj) has one unresolved external symbol for basic_string::basic_string(char const *).
I'm still flummoxed. If you have more ideas, I would really appreciate them.
Indeed, make sure that all the runtimes are the same. This means that the selected runtime to build the DLL should match the runtime used to build the client application. But most of the time this doesn't give any build errors. It will give you strange runtime errors when trying to delete some objects allocated by another runtime version. I remember having a similar problem as the one you described, and the trouble with the code at hand was mixing different header includes. Allways #include <string>, NEVER use the deprecated #include <string.h> (or at least, don't mix them!). The same goes for other standard library header files. Use <iostream> instead <iostream.h>, etc... I hope this will solve your problem. --manu. -- Manu Heirbaut, AGFA R&D Software Engineer. echo mailto: MU!#^:s|mailto|hero!|m|tr 'Mail:nerdhero MU!' loc.altereh@ubrin|rev PGP key @ http://manu.heirbaut.com/PGP.asc [signed or encrypted mail prefered] Advise is what we ask for when we already know the answer but wish we didn't -- Erica Jong
* Jonathan Brownell (alphaomega@p...) wrote:
Thank you all for your prompt responses. I comment further below:
[snip]
Again, my problem when linking with the library in VC6 is that libboost_thread.lib(exceptions.obj) has one unresolved external symbol for basic_string::basic_string(char const *).
I'm still flummoxed. If you have more ideas, I would really appreciate them.
Indeed, make sure that all the runtimes are the same. This means
--- In Boost-Users@y..., Manu Heirbaut <manu@h...> wrote: that
the selected runtime to build the DLL should match the runtime used to build the client application. But most of the time this doesn't give any build errors. It will give you strange runtime errors when trying to delete some objects allocated by another runtime version.
I remember having a similar problem as the one you described, and
trouble with the code at hand was mixing different header includes. Allways #include <string>, NEVER use the deprecated #include <string.h> (or at least, don't mix them!). The same goes for other standard
Usually the result will be link errors, actually. One of the few exceptions to this is mixing debug and release versions. the library
header files. Use <iostream> instead <iostream.h>, etc...
<string.h> is neither deprecated, nor in any way related to <string>. Using them both is very safe and should never cause you problems. The iostream headers are a different issue, though, and in that case they should not be mixed.
I hope this will solve your problem.
His problem has been solved. It was, as I suspected, that he was linking against the static runtime library. Bill Kempf
At 7:57 PM +0000 1/5/02, bill_kempf wrote:
<string.h> is neither deprecated,
Appendix D.5 Standard C library headers [depr.c.headers] leads me to believe otherwise.
nor in any way related to <string>.
Agreed. -- Jon Kalb Kalb@LibertySoft.com
--- In Boost-Users@y..., Jon Kalb <kalb@L...> wrote:
At 7:57 PM +0000 1/5/02, bill_kempf wrote:
<string.h> is neither deprecated,
Appendix D.5 Standard C library headers [depr.c.headers] leads me to believe otherwise.
Splitting hairs. <string.h> is deprecated with preference for <cstring> (not <string>), but the functionality contained in both is identical. The only difference is in which namespace names are placed. This is not the case with <iostream> and <iostream.h>. <iostream.h> is a non-standard header, often still provided by compiler vendors for compatibility with the pre-standard non-template based iostreams. Using <iostream.h> can result in undefined behavior, as is the case when you mix use of it with use of <iostream>, while use of <string.h> is still 100% conforming even if it's use is discouraged in favor of <cstring>. Granted, my statement was not fully correct and likely caused some confusion, but your response just made things worse. Bill Kempf
--- In Boost-Users@y..., "bill_kempf" <williamkempf@h...> wrote:
--- In Boost-Users@y..., Jon Kalb <kalb@L...> wrote:
At 7:57 PM +0000 1/5/02, bill_kempf wrote:
<string.h> is neither deprecated,
Appendix D.5 Standard C library headers [depr.c.headers] leads me to believe otherwise.
Splitting hairs. ...
No. Consider: "These are deprecated features, where deprecated is defined as: Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions." regards, alexander.
--- In Boost-Users@y..., "terekhov" <terekhov@d...> wrote:
--- In Boost-Users@y..., "bill_kempf" <williamkempf@h...> wrote:
--- In Boost-Users@y..., Jon Kalb <kalb@L...> wrote:
At 7:57 PM +0000 1/5/02, bill_kempf wrote:
<string.h> is neither deprecated,
Appendix D.5 Standard C library headers [depr.c.headers] leads me to believe otherwise.
Splitting hairs. ...
No. Consider:
"These are deprecated features, where deprecated is defined as: Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions."
But the features aren't deprecated, only the header is. In other words all the features of the deprecated <string.h> will live on in the non-deprecated <cstring>. Bill Kempf
--- In Boost-Users@y..., "bill_kempf" <williamkempf@h...> wrote:
--- In Boost-Users@y..., "terekhov" <terekhov@d...> wrote:
--- In Boost-Users@y..., "bill_kempf" <williamkempf@h...> wrote:
--- In Boost-Users@y..., Jon Kalb <kalb@L...> wrote:
At 7:57 PM +0000 1/5/02, bill_kempf wrote:
<string.h> is neither deprecated,
Appendix D.5 Standard C library headers [depr.c.headers] leads me to believe otherwise.
Splitting hairs. ...
No. Consider:
"These are deprecated features, where deprecated is defined as: Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions."
But the features aren't deprecated, only the header is. In other words all the features of the deprecated <string.h> will live on in the non-deprecated <cstring>.
But the code might "suddenly" stop compile (1st: missing header; 2nd: global->std name space change) in X years from now and our build/packaging folks just have no idea what <string.h>/<cstring> is and even if they would know how to fix this "small" problem, they are not supposed/ allowed to modify my sources... so, do I want to get a call/fix it later? No! ;-) regards, alexander.
--- In Boost-Users@y..., "terekhov" <terekhov@d...> wrote:
--- In Boost-Users@y..., "bill_kempf" <williamkempf@h...> wrote:
--- In Boost-Users@y..., "terekhov" <terekhov@d...> wrote:
--- In Boost-Users@y..., "bill_kempf" <williamkempf@h...> wrote:
--- In Boost-Users@y..., Jon Kalb <kalb@L...> wrote:
At 7:57 PM +0000 1/5/02, bill_kempf wrote:
<string.h> is neither deprecated,
Appendix D.5 Standard C library headers [depr.c.headers] leads me to believe otherwise.
Splitting hairs. ...
No. Consider:
"These are deprecated features, where deprecated is defined as: Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions."
But the features aren't deprecated, only the header is. In other words all the features of the deprecated <string.h> will live on in the non-deprecated <cstring>.
But the code might "suddenly" stop compile (1st: missing header; 2nd: global->std name space change) in X years from now and our build/packaging folks just have no idea what <string.h>/<cstring> is and even if they would know how to fix this "small" problem, they are not supposed/ allowed to modify my sources... so, do I want to get a call/fix it later? No! ;-)
This thread isn't really worth dragging on. I'll explain once more and then bow out. It was splitting hairs not because I'd correctly stated things. I hadn't. The <string.h> and other C headers are deprecated. It was splitting hairs because I'd clearly explained that use of <string.h> is still supported and fully standards conforming (deprecated features are still conforming, they are only reserved for possible removal in the future). Using <string.h> does not have the same issues as using <iostream.h>. Even though I'd used the wrong language, my very first posting should have made the distinction that <string.h> is conforming and <iostream.h> isn't quite clear. The correction posted ignored this distinction and only pointed out that the headers were in fact deprecated. This response, though more accurate than my original post, was "splitting hairs" in that by ignoring the entire basis of the thread it would lead those that didn't understand this to think that it was, in fact, non-conforming and unsafe to use <string.h> the same as it is for <iostream.h>. Hopefully everyone understands now and there will be no more need for discussion. Bill Kempf
--- In Boost-Users@y..., "cadenzajon" <alphaomega@p...> wrote:
Hi all,
I'm starting to use boost for the first time now, but I'm having problems linking to the thread library (libboost_thread.lib) from within Visual C++.
Using my main compiler, VC++ 6.0, I get the following linker error: libboost_thread.lib(exceptions.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::basic_string<char,struct std::char_traits<ch ar>,class std::allocator<char> >(char const *)"
I'm 99% sure this is caused by not linking against the Multithreaded DLL version of the runtime library. (See another post here for exact directions on changing this.)
I checked the compiler compatibility tables online at the boost site, but they're not recent enough to include any details on the thread library.
Actually, they are recent enough. The problem is that the automated utilities used to generate this table aren't compatible with the structure of Boost.Threads. The Boost.Build system is attempting to address this problem and eventually Boost.Threads will be included in these tables.
When I use Visual C++ .NET (feel free to shrink away in horror) to test it, I get about 8 linker errors complaining that a handful of standard library functions (most dealing with the basic_string and exception classes) are being redefined by libboost_thread.lib.
Also probably caused by not linking against the multithreaded DLL version of the runtime library.
Does anybody have any experience with this or ideas on what I could be doing wrong? I'm just starting to do multi-platform software design, and boost::thread would be a godsend!
I hope this was enough to get you going. If not just ask more questions. Bill Kempf
participants (7)
-
bill_kempf -
cadenzajon -
Jon Kalb -
Jonathan Brownell
-
Manu Heirbaut -
Raul Huertas -
terekhov