Thread: Boost::Regex, MSVC 2008

Ok, this is making me go nuts. I didn't have this problem before and now it just showed up out of the blue.

I can't seem to be able to compile with Boost libraries against the static multi-threaded runtime libraries (debug or release). Only against the DLL versions, which force my app into a vcredist dependency I don't want.

Boost has been installed from the installer provided by Boostpro. I'm using Boost 1.39.0 and installing for VC 9.0. Only this week I finally decided to upgrade boost. And right into this mess.

Error happens at any level, so for simplicity sake I'm copy-pasting here the code from boost documentation:

Code:

#include <boost/regex.hpp>
#include <iostream>
#include <string>

int main()
{
    std::string line;
    boost::regex pat( "^Subject: (Re: |Aw: )*(.*)" );

    while (std::cin)
    {
        std::getline(std::cin, line);
        boost::smatch matches;
        if (boost::regex_match(line, matches, pat))
            std::cout << matches[2] << std::endl;
    }
}

Now, this code is inserted into a new empty project. Runtime library is set to Multi-threaded Debug (/MTd). No other changes to default settings except pointing to boost distribution for include headers and library paths.

The debug library for this runtime is libboost_regex-vc90-sgd-1_39.lib. I try to build without adding it and taking advantage of auto-linking, or by adding it. On both cases the linker fails with:

1>Linking...
1>teste.obj : error LNK2019: unresolved external symbol "public: void __thiscall boost::re_detail::raw_storage::resize(unsigned int)" (?resize@raw_storage@re_detail@boost@@QAEXI@Z) referenced in function "public: void * __thiscall boost::re_detail::raw_storage::extend(unsigned int)" (?extend@raw_storage@re_detail@boost@@QAEPAXI@Z)
1>teste.obj : error LNK2019: unresolved external symbol "public: void * __thiscall boost::re_detail::raw_storage::insert(unsigned int,unsigned int)" (?insert@raw_storage@re_detail@boost@@QAEPAXII@Z) referenced in function "public: struct boost::re_detail::re_syntax_base * __thiscall boost::re_detail::basic_regex_creator<char,struct boost::regex_traits<char,class boost::cpp_regex_traits<char> > >::insert_state(int,enum boost::re_detail::syntax_element_type,unsigned int)" (?insert_state@?$basic_regex_creator@DU?$regex_tra its@DV?$cpp_regex_traits@D@boost@@@boost@@@re_deta il@boost@@QAEPAUre_syntax_base@23@HW4syntax_elemen t_type@23@I@Z)
1>C:\Documents and Settings\Mario Figueiredo\My Documents\Visual Studio 2008\Projects\teste5\Debug\teste5.exe : fatal error LNK1120: 2 unresolved externals
1>Build log was saved at "file://c:\Documents and Settings\Mario Figueiredo\My Documents\Visual Studio 2008\Projects\teste5\teste5\Debug\BuildLog.htm"
1>teste5 - 3 error(s), 0 warning(s)

I'm completely stumped. It just refuses to link against the static runtime.

Not really no, Thanks.

I'm using the right library and I'm statically linking boost::regex too.

I think I'll build the boost distribution myself. It's the only thing that occurs to me. Didn't think that after all this time boostpro would still be distributing a bad lib. But can't think of anything else.

I know it seems wrong, but I've always only been able to build applications (.exe) via Multi-threaded Debug DLL (/MDd) and libboost_regex-vc90-mt-gd-1_39.lib. Wild guess.. it doesn't specify the current project application, but the type in which your application's libraries have been compiled, and your libraries need to match (debug/release, single/multi thread, etc), or else they throw errors.

Originally Posted by Dae

I know it seems wrong, but I've always only been able to build applications (.exe) via Multi-threaded Debug DLL (/MDd) and libboost_regex-vc90-mt-gd-1_39.lib. Wild guess.. it doesn't specify the current project application, but the type in which your application's libraries have been compiled, and your libraries need to match (debug/release, single/multi thread, etc), or else they throw errors.

Yup. that's pretty much my limitation too. Problem with the MT DLL runtimem, to my knowledge is:

- It forces your application into a dependency to MSVCR90.DLL or MSVCP90.DLL depending on whether you are using the C++ standard library. This ought to be distributed with your application since there's no guarantee the user will have it.
- Which in turn force your whole application into a dependency to the Microsoft Visual C++ 2008 SP1 Redistributable Package
- Which in turn force your application to a dependency with the .Net Framework 3.5.

Insane.

I'm on the process to start a manual Boost build and see if I can get working static libs from there. If not... dunno where to file a bug report. If on boost, if on MS.

Originally Posted by Mario F.

- Which in turn force your application to a dependency with the .Net Framework 3.5.

What? Are you sure?
I sincerely don't think so, but seeing as I have Win7, there's no way for me to test that claim...
It should only depend on the run VC++ 2008 runtime, which is all native, no managed, thus no framework.

Also, a thought:
Did you manually try specifying the correct lib file? It would rule out whether it's some configuration problem (ie only linking against the wrong files) or if it's something else.

Originally Posted by Elysia

What? Are you sure?

Not entirely, since when you asked I searched for where I had skimmed through that information sometime earlier. Ayman Shoukry's WebLog : Visual C++ Libraries DLL Deployment

It's on a comment to that article (permalink: Ayman Shoukry's WebLog : Visual C++ Libraries DLL Deployment). But now reading it more carefully, it really makes little sense to me. I could probably test this on a VM. But I'll leave that work for later.

Originally Posted by Elysia

Did you manually try specifying the correct lib file?

Yes, I did. It's on the first post. Am building boost now. We'll see if its a problem with the boostpro distribution.

Originally Posted by Mario F.

- It forces your application into a dependency to MSVCR90.DLL or MSVCP90.DLL depending on whether you are using the C++ standard library. This ought to be distributed with your application since there's no guarantee the user will have it.

true

Originally Posted by Mario F.

- Which in turn force your whole application into a dependency to the Microsoft Visual C++ 2008 SP1 Redistributable Package

true

Originally Posted by Mario F.

- Which in turn force your application to a dependency with the .Net Framework 3.5.

false

Visual Studio with GCC/MinGW (including debugging support) would be the bomb.

There. Solved.

1>teste6 - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Boostpro distribution was at fault. A manual build did it. Dunno why. Couldn't find anyone on the web with a similar problem. Probably because I'm using the Team Suit... but that shouldn't be it.

...on to build the rest of boost.

Originally Posted by Dae

Visual Studio with GCC/MinGW (including debugging support) would be the bomb.

What's wrong with the VC++ compiler?
And on a side note, VS10 should offer build targets, allowing the use of other compilers than VC10.

Mario:
Good luck with the builds and glad it solved the problem.

Originally Posted by Elysia

What's wrong with the VC++ compiler?

Nothing. Besides MinGW is really a bad idea with Boost.

GCC? Now, that's another matter. But there is still no port for windows that gives true credit to GCC quality on Linux. A shame.