Re: [Boost-users] 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
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.
participants (2)
-
gdprosch@micron.com
-
John Maddock