Boost logo

Boost Users :

Subject: Re: [Boost-users] regex: link issue on Visual Studio 11 (v17) x64
From: Oleg Smolsky (oleg.smolsky_at_[hidden])
Date: 2012-03-05 13:42:43

On 2012-03-02 01:49, John Maddock wrote:
>> 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
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.


Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at