Loading ...
Sorry, an error occurred while loading the content.

Using boost::thread under Visual C++

Expand Messages
  • cadenzajon
    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++.
    Message 1 of 15 , Jan 1, 2002
    • 0 Attachment
      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
    • Raul Huertas
      ... 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
      Message 2 of 15 , Jan 2, 2002
      • 0 Attachment
        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@...
        http://www.tcpsi.es




        [Non-text portions of this message have been removed]
      • bill_kempf
        ... 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
        Message 3 of 15 , Jan 2, 2002
        • 0 Attachment
          --- 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
        • bill_kempf
          ... I m 99% sure this was the only problem. ... A good idea in general. ... This shouldn t be necessary. ... I m also not sure that this should be necessary.
          Message 4 of 15 , Jan 2, 2002
          • 0 Attachment
            --- 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

            I'm also not sure that this should be necessary.

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

            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
          • Jonathan Brownell
            ... I already was using the multithreaded libraries. If I had select single-threaded libraries, the boost::thread hpp files would have generated a compiler
            Message 5 of 15 , Jan 2, 2002
            • 0 Attachment
              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
            • bill_kempf
              ... had a ... The key to what I said was _DLL_. There are two multi-threaded libraries, a LIB and a DLL version. ... appreciate ... Insure you re linking
              Message 6 of 15 , Jan 2, 2002
              • 0 Attachment
                --- 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
              • John Maddock
                ... Why not just use your IDE to build threadmon.cpp as a dll, and the rest of the source as a static lib, using whatever your project options are? - John
                Message 7 of 15 , Jan 3, 2002
                • 0 Attachment
                  >I'm still flummoxed. If you have more ideas, I would really appreciate
                  >them.

                  Why not just use your IDE to build threadmon.cpp as a dll, and the rest of
                  the source as a static lib, using whatever your project options are?


                  - John Maddock
                  http://ourworld.compuserve.com/homepages/john_maddock/
                • Manu Heirbaut
                  ... 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
                  Message 8 of 15 , Jan 5, 2002
                  • 0 Attachment
                    * Jonathan Brownell (alphaomega@...) 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
                  • bill_kempf
                    ... symbol ... appreciate ... that ... to ... give any ... Usually the result will be link errors, actually. One of the few exceptions to this is mixing debug
                    Message 9 of 15 , Jan 5, 2002
                    • 0 Attachment
                      --- In Boost-Users@y..., Manu Heirbaut <manu@h...> wrote:
                      > * 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
                      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.

                      Usually the result will be link errors, actually. One of the few
                      exceptions to this is mixing debug and release versions.

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

                      <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
                    • Jon Kalb
                      ... Appendix D.5 Standard C library headers [depr.c.headers] leads me to believe otherwise. ... Agreed. -- Jon Kalb Kalb@LibertySoft.com
                      Message 10 of 15 , Jan 5, 2002
                      • 0 Attachment
                        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@...
                      • bill_kempf
                        ... to ... Splitting hairs. is deprecated with preference for (not ), but the functionality contained in both is identical. The
                        Message 11 of 15 , Jan 7, 2002
                        • 0 Attachment
                          --- 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
                        • terekhov
                          ... No. Consider: These are deprecated features, where deprecated is defined as: Normative for the current edition of the Standard, but not guaranteed to be
                          Message 12 of 15 , Jan 9, 2002
                          • 0 Attachment
                            --- 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.
                          • bill_kempf
                            ... me ... But the features aren t deprecated, only the header is. In other words all the features of the deprecated will live on in the
                            Message 13 of 15 , Jan 9, 2002
                            • 0 Attachment
                              --- 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
                            • terekhov
                              ... leads ... 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
                              Message 14 of 15 , Jan 9, 2002
                              • 0 Attachment
                                --- 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.
                              • bill_kempf
                                ... in ... 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
                                Message 15 of 15 , Jan 10, 2002
                                • 0 Attachment
                                  --- 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
                                Your message has been successfully submitted and would be delivered to recipients shortly.