Boost::Regex runtime link error

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Boost::Regex runtime link error

gdprosch
Boost::Regex runtime link error

I am getting the following runtime link error when running a process that has a dependency on libboost_regex-gcc.so

  ld.so.1: configsrv: fatal: relocation error: file /esdadev/dev/gdprosch/7.1/solaris/debug/lib/libesda.so:
    symbol _ZN5boost11basic_regexIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE9do_assignEPKcS7_j:
    referenced symbol not found

The demangled symbol is…

  nm --demangle ../lib/libesda.so | grep do_assign
     U boost::basic_regex<char, boost::regex_traits<char,
     boost::cpp_regex_traits<char> > >::do_assign(char const*, char const*,  unsigned)

My linkage looks to be okay in my library (libesda.so):

  ldd ../lib/libesda.so | grep boost
    libboost_date_time-gcc.so =>     /esdadev/extsrc/solaris/boost/lib/libboost_date_time-gcc.so
    libboost_filesystem-gcc.so =>    /esdadev/extsrc/solaris/boost/lib/libboost_filesystem-gcc.so
    libboost_regex-gcc.so =>       /esdadev/extsrc/solaris/boost/lib/libboost_regex-gcc.so

The function is in /boost/regex/v4/basic_regex.hpp

   basic_regex& do_assign(const charT* p1,
                          const charT* p2,
                          flag_type f);

I am running on a Solaris 2.8 host where my application and boost 1_33_1 were built using gcc 3.3.1

I have seen two other posting in the archives (V824.1 and V850.3) where other users had similar problems but I saw no resolution posted.

I have verified that the symbol is present in the debug and archive versions of the library and I have even tried linking against those with the same results.

  nm --demangle $BOOST_HOME/lib/libboost_regex-gcc-d.so | grep do_assign
  000a65ac W boost::basic_regex<char, boost::regex_traits<char,
  boost::cpp_regex_traits<char> > >::do_assign(char const*, char const*, unsigned)
  000e3b70 W boost::basic_regex<wchar_t, boost::regex_traits<wchar_t,
  boost::cpp_regex_traits<wchar_t> > >::do_assign(wchar_t const*, wchar_t const*, unsigned)

Any insight would be most helpful.  Thanks in advance :-)

Greg Prosch



_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Boost::Regex runtime link error

gdprosch
RE: Boost::Regex runtime link error

I need to amend my earlier assertion (see below).  I had incorrectly specified my link instructions for static linkage.  If I link against the static library the problem is resolved.  This is, however, undesirable so I would still like to resolve the link issue against the dynamic library.

<< I have verified that the symbol is present in the debug and archive versions of the library and I have even tried linking against those with the same results. >>

Thanks again - Greg


_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Boost::Regex runtime link error

John Maddock
> I need to amend my earlier assertion (see below).  I had incorrectly
> specified my link instructions for static linkage.  If I link against
> the static library the problem is resolved.  This is, however,
> undesirable so I would still like to resolve the link issue against
> the dynamic library.
>
> << I have verified that the symbol is present in the debug and archive
> versions of the library and I have even tried linking against those
> with the same results. >>

I have to admit to having no idea what would cause that: as I understand you
have verified that the symbols are actually in the library, but the runtime
doesn't find them?  You could build your application with
BOOST_REGEX_NO_EXTERNAL_TEMPLATES defined (you may find that you need to
rebuild the libraries with the same define set), which would cause those
template instances to be placed in your object files rather than explicitly
instantiated in the library.  Overall, it'll make your application larger
however, and result in some symbols being duplicated between the lib and
your application.

I'm also confused as to why it's that specific symbol that's causing
problems, if you can figure out what's different about that one, it might
give a clue as to what's going on.  Or on the other hand, maybe that's just
the first failure found :-(

It could also be that some kind of magic build flags are needed to get this
to work on solaris (I know it works on Linux OK, but I don't have access to
a solaris box).

Any gcc-solaris experts lurking out there?

John.

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users