Boost.Regex 1.36.0 fails to compile with VS2005 compiler
Boost.Regex 1.36.0 does not compile due to a compiler specific workaround in files libs\regex\src\usinstances.cpp and libs\regex\src\wc_regex_traits.cpp. The attached patch fixes the problem but will (likely) break linking for others. I use bjam 3.1.13 and obtain this error message: ...patience... ...found 1793 targets... ...updating 618 targets... compile-c-c++ bin.v2\libs\regex\build\msvc-8.0\release\threading-multi\wc_regex_traits.obj wc_regex_traits.cpp libs\regex\src\..\src\wc_regex_traits.cpp(53) : error C2375: 'std::allocator<_Ty>::allocator' : redefinition; different linkage with [ _Ty=unsigned short ] xmemory(120) : see declaration of 'std::allocator<_Ty>::allocator' with [ _Ty=unsigned short ] libs\regex\src\..\src\wc_regex_traits.cpp(53) : error C3190: 'std::allocator<_Ty>::allocator(void) throw()' with the pro vided template arguments is not the explicit instantiation of any member function of 'std::allocator<_Ty>' with [ _Ty=unsigned short ] cl /Zm800 -nologo @"bin.v2\libs\regex\build\msvc-8.0\release\threading-multi\wc_regex_traits.obj.rsp" ...failed compile-c-c++ bin.v2\libs\regex\build\msvc-8.0\release\threading-multi\wc_regex_traits.obj... ...failed updating 1 target... My bjam command line: bjam -q -sNO_COMPRESSION=1 --build-type=complete --without-graph --without-math --without-mpi --without-python --without-serialization --without-signals --without-wave --toolset=msvc-8.0 Regards, Peter. Peter Klotz Software Engineer Phone: +43 (0) 50 8648-4100 Fax: +43 (0) 50 8648-4111 E-Mail: peter.klotz@ith-icoserve.com ---------------------------------------------------------------- ITH icoserve technology for healthcare GmbH A-6020 Innsbruck, Innrain 98 www.ith-icoserve.com Rechtsform: Gesellschaft mit beschränkter Haftung Firmensitz: 6020 Innsbruck, Innrain 98 Firmenbuchnummer: FN 174117f Firmenbuchgericht: Innsbruck DVR: 0983039
Peter Klotz wrote:
Boost.Regex 1.36.0 does not compile due to a compiler specific workaround in files libs\regex\src\usinstances.cpp and libs\regex\src\wc_regex_traits.cpp.
I believe this results from using a copy of VC8 that hasn't had SP1 applied. But can you also try the version of usinstances.cpp in SVN Trunk as I hope this should actually be fixed in there? HTH, John.
John Maddock wrote:
Peter Klotz wrote:
Boost.Regex 1.36.0 does not compile due to a compiler specific workaround in files libs\regex\src\usinstances.cpp and libs\regex\src\wc_regex_traits.cpp.
I believe this results from using a copy of VC8 that hasn't had SP1 applied. But can you also try the version of usinstances.cpp in SVN Trunk as I hope this should actually be fixed in there?
You are right. We use VC8 with a hotfix for the stream memory leak. For several reasons an upgrade to SP1 is not an option. The trunk version of usinstances.cpp still does not compile. I obtain the same error as in 1.36.0. When applying my patch it leads to the linker error which the workaround should prevent. Regards, Peter.
Peter Klotz wrote:
You are right. We use VC8 with a hotfix for the stream memory leak. For several reasons an upgrade to SP1 is not an option.
The trunk version of usinstances.cpp still does not compile. I obtain the same error as in 1.36.0. When applying my patch it leads to the linker error which the workaround should prevent.
Grrrr :-( As a quick and dirty fix, you could try uncommenting the define: // #define BOOST_REGEX_NO_EXTERNAL_TEMPLATES in boost/regex/user.hpp and rebuild everything. Can you let me have the value of _MSC_FULL_VER for the compiler, plus the explicit instantiations at the end of <xstring> (the section that starts #if defined(_DLL_CPPLIB) && !defined(_M_CEE_PURE)). Ah wait, I see I didn't patch usinstances.cpp in SVN, only wc_regex_traits.cpp, so maybe give that one a try as well? If the problem is fixed there, then I think I know what to do to usinstances.cpp. Thanks for your help, and hopefully we can get this fixed! John.
The trunk version of usinstances.cpp still does not compile. I obtain the same error as in 1.36.0. When applying my patch it leads to the linker error which the workaround should prevent.
Grrrr :-(
As a quick and dirty fix, you could try uncommenting the define:
// #define BOOST_REGEX_NO_EXTERNAL_TEMPLATES
in boost/regex/user.hpp and rebuild everything.
Can you let me have the value of _MSC_FULL_VER for the compiler, plus the explicit instantiations at the end of <xstring> (the section that starts #if defined(_DLL_CPPLIB) && !defined(_M_CEE_PURE)).
Ah wait, I see I didn't patch usinstances.cpp in SVN, only wc_regex_traits.cpp, so maybe give that one a try as well? If the problem is fixed there, then I think I know what to do to usinstances.cpp.
The trunk version of wc_regex_traits.cpp compiles, just usinstances.cpp does not.
The value of _MSC_FULL_VER is 140050727.
Here the template instantiations in xstring:
template class _CRTIMP2_PURE allocator<char>;
template class _CRTIMP2_PURE allocator
Peter Klotz wrote:
The trunk version of wc_regex_traits.cpp compiles, just usinstances.cpp does not.
The value of _MSC_FULL_VER is 140050727.
Here the template instantiations in xstring:
Thanks, can you try the attached version of usinstances.cpp to see if it fixes the issue? Cheers, John.
-----Ursprüngliche Nachricht----- Von: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] Im Auftrag von John Maddock Gesendet: Dienstag, 19. August 2008 13:36 An: boost-users@lists.boost.org Betreff: Re: [Boost-users] Boost.Regex 1.36.0 fails to compile with VS2005 compiler
Peter Klotz wrote:
The trunk version of wc_regex_traits.cpp compiles, just usinstances.cpp does not.
The value of _MSC_FULL_VER is 140050727.
Here the template instantiations in xstring:
Thanks, can you try the attached version of usinstances.cpp to see if it fixes the issue?
Compiles and links. Thank you very much for fixing this issue so quick. Regards, Peter.
I'm sorry for silly question: I see there are some bigfixes for Boost 1.36. Will they be applied to the boost_1.36 release archieve? Or they will all appear in smth like Boost 1.36.1 ? I mean can I re-download the latest version of boost like always did (without accessing any trunk) and receive boost with applied bugfixes? Thanks!
Roma.. wrote:
I'm sorry for silly question: I see there are some bigfixes for Boost 1.36. Will they be applied to the boost_1.36 release archieve? Or they will all appear in smth like Boost 1.36.1 ? I mean can I re-download the latest version of boost like always did (without accessing any trunk) and receive boost with applied bugfixes?
They'll be in the next Boost release: whether that will be 1.36.1 or 1.37 remains to be seen, but either way it'll be available about 3 months from now. HTH, John.
participants (4)
-
John Maddock -
Peter Klotz -
Peter Klotz -
Roma..