Boost C++ Libraries: Ticket #12635: Strange undefined reference link errors for boost_regex

John Maddock — Sat, 03 Dec 2016 18:12:09 GMT

What do you mean by "already added libboost_regex library"?

The linker command -lboost_regex should appear *after* all of the object files which use Boost.Regex.

newgen23@… — Fri, 09 Dec 2016 16:04:48 GMT

http://stackoverflow.com/questions/40225571/regex-search-hpp56-undefined-reference-to-boostre-detail-106100perl-match

Same problem.

anonymous — Fri, 09 Dec 2016 19:50:22 GMT

http://stackoverflow.com/questions/40225571/regex-search-hpp56-undefined-reference-to-boostre-detail-106100perl-match

Same problem.

Nope, that's a different issue - that issue is caused by compiling against headers from one version and linking to a library from a different version. That's not supported and never has been, it's just that the issue is caught now. It's also not our problem but a packaging issue somewhere downstream...

anonymous — Fri, 09 Dec 2016 20:06:07 GMT

Replying to anonymous:

http://stackoverflow.com/questions/40225571/regex-search-hpp56-undefined-reference-to-boostre-detail-106100perl-match

Same problem.

Nope, that's a different issue - that issue is caused by compiling against headers from one version and linking to a library from a different version. That's not supported and never has been, it's just that the issue is caught now. It's also not our problem but a packaging issue somewhere downstream...

A packaging issue downstream? For Version 1.60, 1.61 and 1.62 ? Is there any way to find out whats inside /usr/lib/i386-linux-gnu/libboost_regex.so.1.60.0 ?

John Maddock — Sat, 10 Dec 2016 18:43:24 GMT

Sorry I was a bit short and harsh:

Boost has never supported binary compatibility between releases, if you compile against one versions headers and link to another versions .so file, bad stuff will happen somewhere down the road.
Recent Boost.Regex releases have enforced this by mangling their namespace with the Boost version number - the only difference from previous releases is that now you're prevented from shooting yourself in the foot quite so often ;)
If you just specify -lboost_regex on the command line, you will presumably link against whatever version was installed by the official system package. Use the "file" command to discover where libboost_regex.so points.
If you manually install a later version, or use a package someone has prepared, then there are a whole host of possible build options that are outside our control - in particular they may install the binaries in a location not searched by default (such as /usr/local/lib), but you will need to consult the package builders own documentation on this. You may also need to link against a specific version if the libboost_regex symlink has not been over-written.
If in doubt you can see what symbols are exported from a library with "nm -gC libraryname.so"

shaohua199@… — Tue, 03 Jan 2017 03:24:00 GMT

Hi,

This problem is resolved.

After I use "nm -gC libboost_regex.so" command to check my library, I find the 0000000000051370 W boost::re_detail_106000::perl_matcher<boost::re_detail_106000::mapfile_iterator, stl::allocator<boost::sub_match<boost::re_detail_106000::mapfile_iterator> >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::construct_init(boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags)

And my link error is: error: undefined reference to 'boost::re_detail_106000::perl_matcher<char const*, stlp_std::allocator<boost::sub_match<char const*> >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::construct_init(boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags)'

So it is caused by my application use stlport library. After I re-compile boost library with "stdlib=stlport" option and specified "using stlport" in project-config.jam file, the link process is OK now.

Thanks very much for your help.

Thanks, Shaohua

status changed; resolution set

John Maddock — Thu, 09 Feb 2017 19:10:08 GMT

status new → closed
resolution → invalid