Hey there, I've just built Boost 1.49 with Visual Studio 11 (cl.exe v17) and that worked (bjam knows about the compiler version already). I do get a linking issue though when using regex in a debug/x64 (static boost, static run-time) build:
unresolved external symbol "private: class boost::basic_regex<wchar_t,........ unresolved external symbol "public: bool __cdecl boost::re_detail::perl_matcher<wchar_t const *, unresolved external symbol "private: void __cdecl boost::re_detail::perl_matcher<wchar_t const *,
The issue surfaces when calling boost::regex_match() with a boost::wregex expression.
Here are some debugging notes:
a.. This same application linked against Boost 1.48 using Visual Studio 2010 (cl.exe v16). This build did not have ICU.
b.. I have just built ICU and fed it too bjam's command line (-sICU_PATH=....), both 32- and 64-bit versions were detected, regex was built. Yet it made no difference to the final link step.
It seems the issue is not related to ICU... I am guessing regex speaks unicode using a specific Windows backend, but I am lost here. Could someone help debugging this please?
Not much as I don't have VS11. Things to check: * Are the libraries really 64 bit ones, or were 32 bit ones built by mistake? * Does a hello world app that uses boost::regex work? * Take a peek inside the libraries and see what symbols are defined - there should be both wchar_t and unsigned short versions in there. If all else fails and you just want to move on - define BOOST_REGEX_NO_LIB in your project, and build Boost.Regex as a dll or static lib project in your IDE - it's "just a bunch of source files" in libs/regex/src, nothing special about building it. HTH, John.
Hey there, I've just built Boost 1.49 with Visual Studio 11 (cl.exe v17) and that worked (bjam knows about the compiler version already). I do get a linking issue though when using regex in a debug/x64 (static boost, static run-time) build:
unresolved external symbol "private: class boost::basic_regex<wchar_t,........ unresolved external symbol "public: bool __cdecl boost::re_detail::perl_matcher<wchar_t const *, unresolved external symbol "private: void __cdecl boost::re_detail::perl_matcher<wchar_t const *,
The issue surfaces when calling boost::regex_match() with a boost::wregex expression.
Here are some debugging notes:
a.. This same application linked against Boost 1.48 using Visual Studio 2010 (cl.exe v16). This build did not have ICU.
b.. I have just built ICU and fed it too bjam's command line (-sICU_PATH=....), both 32- and 64-bit versions were detected, regex was built. Yet it made no difference to the final link step.
It seems the issue is not related to ICU... I am guessing regex speaks unicode using a specific Windows backend, but I am lost here. Could someone help debugging this please?
Not much as I don't have VS11.
Things to check:
* Are the libraries really 64 bit ones, or were 32 bit ones built by mistake? * Does a hello world app that uses boost::regex work? * Take a peek inside the libraries and see what symbols are defined - there should be both wchar_t and unsigned short versions in there.
If all else fails and you just want to move on - define BOOST_REGEX_NO_LIB in your project, and build Boost.Regex as a dll or static lib project in your IDE - it's "just a bunch of source files" in libs/regex/src, nothing special about building it. Right, I had disassembled some of the .obj files from inside the static
On 2012-03-02 01:49, John Maddock wrote: lib, and not only the symbols were there, but the code was AMD64. Yet the linker was complaining about the missing symbols. I have just tried a normal (narrow char) test and got a very similar linking error. Then rebuilt regex and voila - everything links and runs. Including the wide variant. This is crazy... Either the linker has a sly bug or bjam produced a library using some strange command-line option... (VS comes with x86, x64 and a x86/x64 cross compiler. I have just tried both native-x64 and cross-compiler environments, both work). Other than that I have no clue. Thanks John. I'll drop a line to the list if this happens again and I am able to extract the exact definition of the issue. Oleg.
participants (2)
-
John Maddock -
Oleg Smolsky