- Boost-users - lists.boost.org

some warning C4273: inconsistent dll linkage
by Alex Perry 18 Nov '11

18 Nov '11

On Thu, 17 Nov 2011 12:07:57 -0800 (PST) code <b4code(a)yahoo.com> wrote:- > Hi Boost Users, > > When I compiled and linked my projects with Boost libraries, I got the > following warnings > ...snip... > I want to link Boost.thread dll dynamically and other Boost libraries statically. > > If I set #define BOOST_ALL_DYN_LINK, I could not generate ...snip... I didn't see any answer to this but apologies if its already been answered. #define BOOST_ALL_DYN_LINK Is for use within your own consuming code - use the bjam --link option to control which version of boost libraries are built eg in boost root do:- bjam variant=debug,release threading=multi link=shared stage --with-thread which would build boost-thread as dll (bjam --help to get more info on options) then: #define BOOST_THREAD_DYN_LINK In your code would use the dll version of boost.thread (any other boost libs would still be looking for static versions) HTH Alex

2 1

Re: [Boost-users] Boost 1.48.0 Release Notice
by Andrew Maclean 18 Nov '11

18 Nov '11

> > ---------- Forwarded message ---------- > From: Michael Jackson <imikejackson(a)gmail.com> > To: boost-users(a)lists.boost.org > Date: Wed, 16 Nov 2011 10:27:18 -0500 > Subject: Re: [Boost-users] Boost 1.48.0 Release Notice > On 11/16/11 10:05 AM, in article > CAArKS8i9AtMcQhRtxt81LQZm4vTVeanhuhQLFgVBjahLv+oJxw(a)mail.gmail.com, "Tom > Kent" wrote: > > >> Subject: [Boost-users] Boost 1.48.0 Release Notice > >> From: Beman Dawes (bdawes_at_[hidden]) > >> Date: 2011-11-16 07:33:06 > >> > >> Release 1.48.0 of the Boost C++ Libraries is now available. > >> These open-source libraries work well with the C++ Standard Library, > >> and are usable across a broad spectrum of applications. The Boost > >> license encourages both commercial and non-commercial use. > >> This release contains new libraries: Container, Locale, Move. Updated > >> libraries include: Asio, Chrono, Config, Fusion, Geometry, Graph, > >> Interprocess, Intrusive, Lexical cast, Math, MSM, Numeric Conversion, > >> Proto, Regex, Spirit, TypeTraits, Unordered, Wave, and more. For > >> details, including download links, see > >> http://www.boost.org/users/news/version_1_48_0 > >> You can also download directly from SourceForge: > >> http://sourceforge.net/projects/boost/files/boost/1.48.0/ > >> To install this release on your system, see > >> http://www.boost.org/doc/libs/release/more/getting_started/index.html > >> Thanks, > >> --The Boost release team > >> Beman Dawes > >> Daniel James > >> Eric Niebler > >> Rene Rivera > >> Vladimir Prus > > > > > > I've built windows libraries (vc8, vc9, vc10) for this (32 and 64 > > bit), if you want them, you can get them from my website: > > http://boost.teeks99.com > > Tom > > What exact versions of each of those did you use? Were they > single/multi-threaded, Static/Shared... > > Thanks > Mike Jackson > > > Hi Tom, You have done a really splendid job which will save us many hours of compilation! I had a brief look, and all the libraries seem to be there except the following: libboost_bzip2-vc*.lib libboost_zlib-vc*.lib boost_bzip2-vc*.dll boost_zlib*-vc.dll boost_bzip2-vc*.libl boost_zlib*-vc.libl These are used by the iostreams compressors and decompressors. These are really an integral part of iostreams. Would it be possible to include these too? Regards Andrew -- ___________________________________________ Andrew J. P. Maclean Australian Centre for Field Robotics (ACFR) The Rose Street Building J04 The University of Sydney 2006 NSW AUSTRALIA Ph: +61 2 9351 3283 Fax: +61 2 9351 7474 URL: http://www.acfr.usyd.edu.au/ ___________________________________________

5 7

Segfaults w/ Program_options in __run_exit_handlers : gcc45
by Keith Gunderson 18 Nov '11

18 Nov '11

I am tracking down some segfaults that may be related to the Program Options library. I've done my best to narrow the focus of what I'm doing and seeing. Now I'll report the results and see if anyone can help me get to the bottom of the issue. Overview: Two C++ projects, a library (LIB) and an app (APP). Both developed in OpenSuse 11.3 using gcc45 and boost 1_45. Both built using CMake(makefiles), and share the same boost settings in a shared cmake file (settings listed later.) LIB is linked into APP (either staticly or dynamically , as discussed later.) Both LIB and APP contain a options[Lib|App].cpp file that defines an uniquely named options global object. These objects store the option values as members and have a ParseOptions() method that use the Boost Program Options features. There is an exported API call in LIB that passes a string into the optionsLib object. Now I'll start listing some known facts about how/when segfaults are seen. 1: Crashes never occur in Windows (using VC++10). 2: If everything is linked statically, there is never a segfault. (There are three linkages in question: APP->Boost, LIB->Boost, APP->LIB) 3: If everything is linked dynamically there is never a segfault. 4: Segfaults occur when APP->LIB is dynamic while APP->Boost and LIB->Boost are linked statically. This situation occurs even if a global options object in APP is never instantiated (but the options.cpp is still a part of the project) It seems that the segfault occurs in the exit handlers. I posted some of a gdb session that shows some of the exit functions that are called. ************************************************************* Here are the settings in CMake for the segfault situation: set (Boost_ADDITIONAL_VERSIONS "1.46" "1.46.0" "1.45" "1.45.0" "1.44" "1.44.0" "1.43" "1.43.0") set (Boost_USE_MULTITHREADED ON) set (Boost_USE_STATIC_LIBS ON) set (Boost_USE_STATIC_RUNTIME OFF) find_package( Boost 1.41.0 COMPONENTS "program_options" "filesystem" "system") ************************************************************* Here's the way that boost::po is used #note that things like loggins have been stripped out int AppOptions::ParseOptions(std::vector<std::basic_string<char> > optionsStrings ) { try { // Declare a group of options that will be // allowed only on command line po::options_description generic("Generic options"); generic.add_options() ("version,v", "Print version string") ("help", "Produce help message") ("config-file,c", po::value<string>(&configFileName_)->default_value(configFileName_), "Name of a file for configuration.") ; #pragma warning( push ) #ifdef _WINDOWS #pragma warning( disable : 4505 ) #endif // Declare a group of options that will be // allowed both on command line and in // config file po::options_description config("Configuration"); config.add_options() ("energy-dir,e", po::value< string >(&energyDir_)->default_value(energyDir_), "Path containing energy files") ("run-example", po::bool_switch(&runExample_), "Use example file (./example_input.txt) instead of stdin for input.") ("old-output-format", po::bool_switch(&useOldOutputFormat_), "Generate output in the old format, for compatibility reasons") ; #pragma warning( pop ) po::options_description cmdline_options; cmdline_options.add(generic).add(config); po::options_description config_file_options; config_file_options.add(config); po::options_description visible("Allowed options"); visible.add(generic).add(config); po::variables_map vm; po::parsed_options options = po::command_line_parser(optionsStrings). options(cmdline_options).allow_unregistered().run(); store(options, vm); notify(vm); std::stringstream ss; ss << "App cmd-line options (plus defaults): " << std::endl;; ss << "\t" << "config_file=" << configFileName_ << std::endl; ss << "\t" << "energy-dir=" << energyDir_ << std::endl; ss << "\t" << "run-example=" << runExample_ << std::endl; ss << "\t" << "old-output-format=" << useOldOutputFormat_<< std::endl; // pantheios::log_DEBUG( EX_PREFIX, "Config : ", ss.str().c_str() ); std::vector<string> to_pass_further = po::collect_unrecognized(options.options, po::exclude_positional); if (configFileName_.size()) { std::ifstream ifs(configFileName_.c_str()); if (!ifs) { std::stringstream ss; ss << "can not open config file: " << configFileName_ << std::endl;; ss << "creating default config file: " << configFileName_ << std::endl;; // pantheios::log_DEBUG( EX_PREFIX, "Config file error: ", ss.str().c_str() ); std::ofstream ofs(configFileName_.c_str()); ofs << "energy-dir = SET/LOCATION/TO/ENERGY/FILES" << std::endl; ofs.close(); return 1; } else { po::parsed_options file_options = parse_config_file(ifs, config_file_options); store(file_options, vm); notify(vm); std::stringstream ss; ss << "App post config-file options: " << std::endl;; ss << "\t" << "config_file=" << configFileName_ << std::endl; ss << "\t" << "energy-dir=" << energyDir_ << std::endl; ss << "\t" << "run-example=" << runExample_ << std::endl; ss << "\t" << "old-output-format=" << useOldOutputFormat_<< std::endl; // pantheios::log_DEBUG( EX_PREFIX, "Config : ", ss.str().c_str() ); } } if (vm.count("help")) { std::cout << visible << "\n"; to_pass_further.push_back( "--help"); return 1; } if (vm.count("version")) { std::cout << "App version " << APP_FULL_VERSION << std::endl ; return 1; } } catch(std::exception const & e) { std::stringstream ss; ss << "Configuration exception: " << e.what() << std::endl; // pantheios::log_DEBUG( EX_PREFIX, "", ss.str().c_str() ); return 1; } return 0; } ************************************************************* gdb session Breakpoint 2, __run_exit_handlers (status=0, listp=0xb7ca2304, run_list_atexit=true) at exit.c:78 (gdb) step (gdb) next (gdb) step std::ios_base::Init::~Init (this=0x80da45c, __in_chrg=<value optimized out>) at ../../../../libstdc++-v3/src/ios_init.cc:123 (gdb) cont Continuing. Breakpoint 2, __run_exit_handlers (status=0, listp=0xb7ca2304, run_list_atexit=true) at exit.c:78 (gdb) step (gdb) next (gdb) step std::ios_base::Init::~Init (this=0x80da46d, __in_chrg=<value optimized out>) at ../../../../libstdc++-v3/src/ios_init.cc:123 (gdb) cont Continuing. Breakpoint 2, __run_exit_handlers (status=0, listp=0xb7ca2304, run_list_atexit=true) at exit.c:78 (gdb) step (gdb) next (gdb) step (gdb) cont Continuing. Breakpoint 2, __run_exit_handlers (status=0, listp=0xb7ca2304, run_list_atexit=true) at exit.c:78 (gdb) step (gdb) next (gdb) step boost::program_options::detail::utf8_codecvt_facet::~utf8_codecvt_facet (this=0x80da4c4, __in_chrg=<value optimized out>) at ./boost/detail/utf8_codecvt_facet.hpp:108 (gdb) cont Continuing. Breakpoint 2, __run_exit_handlers (status=0, listp=0xb7ca2304, run_list_atexit=true) at exit.c:78 (gdb) step (gdb) next (gdb) step std::ios_base::Init::~Init (this=0x80da4b8, __in_chrg=<value optimized out>) at ../../../../libstdc++-v3/src/ios_init.cc:123 (gdb) cont Continuing. Breakpoint 2, __run_exit_handlers (status=0, listp=0xb7ca2304, run_list_atexit=true) at exit.c:78 (gdb) step (gdb) next (gdb) step std::ios_base::Init::~Init (this=0x80da4d0, __in_chrg=<value optimized out>) at ../../../../libstdc++-v3/src/ios_init.cc:123 (gdb) cont Continuing. Breakpoint 2, __run_exit_handlers (status=0, listp=0xb7ca2304, run_list_atexit=true) at exit.c:78 (gdb) step (gdb) next (gdb) step __pthread_mutex_lock (mutex=0xb7fff4e4) at pthread_mutex_lock.c:47 (gdb) cont Continuing. *** glibc detected *** /home/turkey/PT-6/APP: double free or corruption (fasttop): 0x080dca38 *** ======= Backtrace: ========= /lib/libc.so.6(+0x6dffb)[0xb7ba8ffb] /lib/libc.so.6(+0x6ed7b)[0xb7ba9d7b] /lib/libc.so.6(cfree+0x6d)[0xb7badadd] /usr/lib/libstdc++.so.6(_ZdlPv+0x1f)[0xb7da198f] /usr/lib/libstdc++.so.6(_ZNSs4_Rep10_M_destroyERKSaIcE+0x1b)[0xb7d8205b] /usr/lib/libstdc++.so.6(_ZNSsD1Ev+0x4a)[0xb7d8210a] /lib/libc.so.6(__cxa_finalize+0xab)[0xb7b69b4b] /home/turkey/OC-6/libLIB22.so(+0xf9e74)[0xb7ed8e74] /home/turkey/OC-6/libLIB22.so(+0x176b90)[0xb7f55b90] /lib/ld-linux.so.2(+0xed1d)[0xb7fedd1d] /lib/libc.so.6(+0x2e7cf)[0xb7b697cf] ======= Memory map: ======== 08048000-080d9000 r-xp 00000000 fd:00 264869 /home/turkey/PT-6/APP 080d9000-080da000 r--p 00090000 fd:00 264869 /home/turkey/PT-6/APP 080da000-080db000 rw-p 00091000 fd:00 264869 /home/turkey/PT-6/APP 080db000-080fc000 rw-p 00000000 00:00 0 [heap] b7900000-b7921000 rw-p 00000000 00:00 0 b7921000-b7a00000 ---p 00000000 00:00 0 b7af7000-b7af9000 r-xp 00000000 fd:01 6992 /usr/lib/gconv/ISO8859-1.so b7af9000-b7afa000 r--p 00001000 fd:01 6992 /usr/lib/gconv/ISO8859-1.so b7afa000-b7afb000 rw-p 00002000 fd:01 6992 /usr/lib/gconv/ISO8859-1.so b7afb000-b7b02000 r--s 00000000 fd:01 7064 /usr/lib/gconv/gconv-modules.cache b7b02000-b7b39000 r--p 00000000 fd:01 7759 /usr/lib/locale/en_US/LC_CTYPE b7b39000-b7b3b000 rw-p 00000000 00:00 0 b7b3b000-b7c9f000 r-xp 00000000 fd:01 158 /lib/libc-2.11.2.so b7c9f000-b7ca0000 ---p 00164000 fd:01 158 /lib/libc-2.11.2.so b7ca0000-b7ca2000 r--p 00164000 fd:01 158 /lib/libc-2.11.2.so b7ca2000-b7ca3000 rw-p 00166000 fd:01 158 /lib/libc-2.11.2.so b7ca3000-b7ca6000 rw-p 00000000 00:00 0 b7ca6000-b7cc2000 r-xp 00000000 fd:01 249 /lib/libgcc_s.so.1 b7cc2000-b7cc3000 r--p 0001b000 fd:01 249 /lib/libgcc_s.so.1 b7cc3000-b7cc4000 rw-p 0001c000 fd:01 249 /lib/libgcc_s.so.1 b7cc4000-b7cc5000 rw-p 00000000 00:00 0 b7cc5000-b7ced000 r-xp 00000000 fd:01 243 /lib/libm-2.11.2.so b7ced000-b7cee000 r--p 00027000 fd:01 243 /lib/libm-2.11.2.so b7cee000-b7cef000 rw-p 00028000 fd:01 243 /lib/libm-2.11.2.so b7cef000-b7dd3000 r-xp 00000000 fd:01 6775 /usr/lib/libstdc++.so.6.0.14 b7dd3000-b7dd7000 r--p 000e3000 fd:01 6775 /usr/lib/libstdc++.so.6.0.14 b7dd7000-b7dd8000 rw-p 000e7000 fd:01 6775 /usr/lib/libstdc++.so.6.0.14 b7dd8000-b7ddf000 rw-p 00000000 00:00 0 b7ddf000-b7fa8000 r-xp 00000000 fd:00 305471 /home/turkey/OC-6/libLIB22.so b7fa8000-b7faa000 r--p 001c8000 fd:00 305471 /home/turkey/OC-6/libLIB22.so b7faa000-b7faf000 rw-p 001ca000 fd:00 305471 /home/turkey/OC-6/libLIB22.so b7faf000-b7fb0000 rw-p 00000000 00:00 0 b7fb0000-b7fc7000 r-xp 00000000 fd:01 183 /lib/libpthread-2.11.2.so b7fc7000-b7fc8000 r--p 00016000 fd:01 183 /lib/libpthread-2.11.2.so b7fc8000-b7fc9000 rw-p 00017000 fd:01 183 /lib/libpthread-2.11.2.so b7fc9000-b7fcb000 rw-p 00000000 00:00 0 b7fcf000-b7fd0000 r--p 00000000 fd:01 131840 /usr/lib/locale/en_US/LC_IDENTIFICATION b7fd0000-b7fd1000 r--p 00000000 fd:01 131586 /usr/lib/locale/en_US/LC_MEASUREMENT b7fd1000-b7fd2000 r--p 00000000 fd:01 8241 /usr/lib/locale/en_US/LC_TELEPHONE b7fd2000-b7fd3000 r--p 00000000 fd:01 131842 /usr/lib/locale/en_US/LC_ADDRESS b7fd3000-b7fd4000 r--p 00000000 fd:01 8242 /usr/lib/locale/en_US/LC_NAME b7fd4000-b7fd5000 r--p 00000000 fd:01 8245 /usr/lib/locale/en_US/LC_PAPER b7fd5000-b7fd6000 r--p 00000000 fd:01 8240 /usr/lib/locale/en_US/LC_MESSAGES/SYS_LC_MESSAGES b7fd6000-b7fd7000 r--p 00000000 fd:01 131838 /usr/lib/locale/en_US/LC_MONETARY b7fd7000-b7fdc000 r--p 00000000 fd:01 7761 /usr/lib/locale/en_US/LC_COLLATE b7fdc000-b7fdd000 r--p 00000000 fd:01 131839 /usr/lib/locale/en_US/LC_TIME b7fdd000-b7fde000 r--p 00000000 fd:01 7927 /usr/lib/locale/en_US/LC_NUMERIC b7fde000-b7fdf000 rw-p 00000000 00:00 0 b7fdf000-b7ffe000 r-xp 00000000 fd:01 296 /lib/ld-2.11.2.so b7ffe000-b7fff000 r--p 0001e000 fd:01 296 /lib/ld-2.11.2.so b7fff000-b8000000 rw-p 0001f000 fd:01 296 /lib/ld-2.11.2.so bffdf000-c0000000 rw-p 00000000 00:00 0 [stack] ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso] Program received signal SIGABRT, Aborted. 0xffffe424 in __kernel_vsyscall () Thanks for any help in determining if the crash is caused by me or not. Keith

2 1

Re: [Boost-users] Building Boost 1.48 using Intel compiler
by Edward Rankin 18 Nov '11

18 Nov '11

Hi, Just a general comment for compiling Boost with Intel compiler. I have been compiling boost with Intel-win for a while now, and I usually use the command prompt shortcut which comes with the compiler. This will set up the environment correctly. I have been working in Linux recently, so have not tried out Intel 12.1 and Boost 1.47 (now 1.48), so something must have changed on either side. I will see if I can build it this weekend. I do recall there were some changes from 11.1 to 12.0 which caused a lot of deprecation warnings (something to do with where iclvars.bat is located). I am not sure if this was ever fixed (i did create a ticket here: https://svn.boost.org/trac/boost/ticket/5305) Of course this is only important if you run a standard command prompt (and not the Intel one). Regards, Edward

1 0

Build boost.log
by Konstantin Ribel 18 Nov '11

18 Nov '11

2 2

Re: [Boost-users] recursive_variant map recursion / incomplete type error
by 乔志强 18 Nov '11

18 Nov '11

try #define BOOST_VARIANT_NO_FULL_RECURSIVE_VARIANT_SUPPORT MSVC++ 2010 and gcc maybe need this. ------------------------------ Message: 4 Date: Thu, 17 Nov 2011 11:10:27 +0100 From: "Bodmer Marc" <Marc.Bodmer(a)bystronic.com> To: <boost-users(a)lists.boost.org> Subject: [Boost-users] recursive_variant map recursion / incomplete type error Message-ID: <0456E5B751F6DB4A83688EED49C9CAF70E101094(a)CHNIS191.bystronic.metal.firm> Content-Type: text/plain; charset="utf-8" Hi I try to use boost::recursive_variant with a recursive std::map. There are several projects and examples on the internet using boost::recursive_variant exactly like I do and it seems to work there. But somehow I can not make it compile in my environment. I am using gcc 4.6.1 and boost 1.46.1. I've stripped my code down to this: ------------------------------------------------------------- #include <boost/variant.hpp> #include <map> typedef boost::make_recursive_variant< int, std::map<float, boost::recursive_variant_> >::type element; int main () { element i = 42; }

2 1

[foreach] #define foreach BOOST_FOREACH
by Joaquin M Lopez Munoz 18 Nov '11

18 Nov '11

In Boost.Foreach docs, the user is informed about the possibility to do #define foreach BOOST_FOREACH so as to improve readability, provided there's no collisions in her code with the name 'foreach'. I think this advise is extremely unfortunate, because the collision happens right within Boost.Foreach code itself, as it uses the namespace boost::foreach internally. This results in problems like the one described in http://lists.boost.org/boost-users/2011/11/71762.php I think the only viable fix is to rename boost::foreach as boost::foreach_ or something and assume backwards incompatibility (as for Boost.MultiIndex, I'd have no problem in syncing up), unless someone figures out a smarter workaround. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

[inteprocess] Using named_mutex on Windows 7
by Edward Diener 18 Nov '11

18 Nov '11

I wrote a program more than 3 years ago where I used boost::interprocess_named_mutex to protect more than one instance of the same process from running the same sequence of code at the same time. The program appears to run fine under Windows XP and Windows Vista but occasionally locks up waiting for the locked mutex to unlock on Windows 7. The code looks like this: ------------------------------------------------------------------- boost::interprocess::named_mutex cmutex(boost::interprocess::open_or_create_t(),"MyMutexName"); { boost::interprocess::scoped_lock<boost::interprocess::named_mutex> cscoped(cmutex); // Code here which must be run one at a time. } ------------------------------------------------------------------- Under Windows 7 the code occasionally hangs on the scoped_lock instantiation, which of course I can not have. I notice there is a file in the temporary directory ( TMP or TEMP environment variable ) which is being used by interprocess, and after that file is manually deleted, the program no longer hangs on the scoped_lock instantiation. Is there a reason for this problem on Windows 7 ? I know that Windows 7 has global and local named mutexes and only by prefacing a named mutex name with global\ is the mutex truly global. I do not know if this is causing the problem on Windows 7. It does seem as if something in the file in the temporary directory is telling inteprocess that "MyMutexName" is still locked when the hangup occurs, but I would have expected that when acoped_lock goes out of scope, it handles resetting that file to the correct state. I wonder if this has something to do with UAC/file permissions in Windows 7, where the process somehow can no longer write to the file in the temporary directory afte creating it. Is this a known interprocess problem, perhaps fixed in a later release ? I wrote my code before Windows 7 even came out, recompiled it for Windows 7, but did not update the version of Boost I was using ( Boost 1.35 ). Maybe I need to do that ? I would certainly be willing to do that if I knew that this was a problem with interprocess in Boost 1.35 that has subsequently been fixed in a later version of Boost.

1 0

Re: [Boost-users] Boost 1.48.0 Release Notice
by Tom Kent 18 Nov '11

18 Nov '11

> > Subject: Re: [Boost-users] Boost 1.48.0 Release Notice > From: Michael Jackson (imikejackson_at_[hidden]) > Date: 2011-11-16 10:27:18 > On 11/16/11 10:05 AM, in article > CAArKS8i9AtMcQhRtxt81LQZm4vTVeanhuhQLFgVBjahLv+oJxw_at_[hidden], "Tom > Kent" wrote: > >> Subject: [Boost-users] Boost 1.48.0 Release Notice > >> From: Beman Dawes (bdawes_at_[hidden]) > >> Date: 2011-11-16 07:33:06 > >> > >> Release 1.48.0 of the Boost C++ Libraries is now available. > >> These open-source libraries work well with the C++ Standard Library, > >> and are usable across a broad spectrum of applications. The Boost > >> license encourages both commercial and non-commercial use. > >> This release contains new libraries: Container, Locale, Move. Updated > >> libraries include: Asio, Chrono, Config, Fusion, Geometry, Graph, > >> Interprocess, Intrusive, Lexical cast, Math, MSM, Numeric Conversion, > >> Proto, Regex, Spirit, TypeTraits, Unordered, Wave, and more. For > >> details, including download links, see > >> http://www.boost.org/users/news/version_1_48_0 > >> You can also download directly from SourceForge: > >> http://sourceforge.net/projects/boost/files/boost/1.48.0/ > >> To install this release on your system, see > >> http://www.boost.org/doc/libs/release/more/getting_started/index.html > >> Thanks, > >> --The Boost release team > >> Beman Dawes > >> Daniel James > >> Eric Niebler > >> Rene Rivera > >> Vladimir Prus > > > > > > I've built windows libraries (vc8, vc9, vc10) for this (32 and 64 > > bit), if you want them, you can get them from my website: > > http://boost.teeks99.com > > Tom > What exact versions of each of those did you use? Were they > single/multi-threaded, Static/Shared... > Thanks > Mike Jackson I believe I have all the various combinations: mt, mt-gd, mt-s, s, sgd, mt dll, mg-gd dll Tom

1 0

4 link errors related to boost_thread_vc100_mt-1_47 libraries
by code 17 Nov '11

17 Nov '11

Hi Boost users, I built boost_thread_vc100_mt-1_47.lib and boost_thread_vc100_mt-1_47.dll successfully by using 1_47 source codes without changing any thing. When I used the libraries in my project, I got the following link errors: 1>boost_UT.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static void __cdecl boost::thread::sleep(class boost::posix_time::ptime const &)" (__imp_?sleep@thread@boost@@SAXABVptime@posix_time@2@@Z) 1>boost_UT.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) private: static class boost::intrusive_ptr<struct boost::detail::thread_data_base> __cdecl boost::thread::make_thread_info(void (__cdecl*)(void))" (__imp_?make_thread_info@thread@boost@@CA?AV?$intrusive_ptr@Uthread_data_base@detail@boost@@@2@P6AXXZ@Z) 1>boost_UT.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl boost::detail::free_raw_heap_memory(void *)" (__imp_?free_raw_heap_memory@detail@boost@@YAXPAX@Z) 1>boost_UT.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void * __cdecl boost::detail::allocate_raw_heap_memory(unsigned int)" (__imp_?allocate_raw_heap_memory@detail@boost@@YAPAXI@Z) Can somebody kindly help me figure out a solution to fix them? Thank you Yan My working environment: Windows 7 + Visual Studio VC++10.

3 5