Hi, It's a while now since the review of John Torjo's Logging library was concluded, and I'm curious to know what the result was. Is it still being considered? Thanks, Colin
cat test.cpp #include <boost/regex.hpp> using namespace boost; int main (void) { regex expr("foo"); return 0; } g++ -I sources/3rdParty/boost -I sources/3rdParty/local-config/linux/ -Lsources/3rdParty/releases/linux/debug [works] g++ -I sources/3rdParty/boost -I sources/3rdParty/local-config/linux/ -Lsources/3rdParty/releases/linux/release
Hello all. I am having problems compiling with boost 1.34.1 regex in release on linux (RedHat kernel 2.4.21-4.Elsmp/i686) I get the following (using a simple test case that seems to reproduce the problem): sources/3rdParty/releases/linux/release//libboost_regex.so: undefined reference to 'boost::re_detail::cpp_regex_traits_implementation<char>::isctype(char, unsigned) const' collect2: ld returned 1 exit status The following includes information used to compile the release build, taken from config.status (with some unnecessary defines cleaned up). Note that a very similar line is executed to create the debug executables, the only real difference is that debug does not have -O3 and defines instead of NDEBUG the macros DEBUG and _DEBUG. // Use this file to define a site and compiler specific // configuration policy, this version was auto-generated by // configure on Wed Mar 5 16:04:54 IST 2008 // With the following options: // CXX = /usr/local/bin/distcc /usr/local/bin/g++ // CXXFLAGS = -I sources/3rdParty/boost/libs/config/../.. -I sources/3rdParty/boost/libs/config/../../libs/config/test -ggdb -DNDEBUG -pthread -fPIC -fnon-call-exceptions -DNO_WIN32 -DTCHAR=wchar_t -DUNICODE -D_REENTRANT -D_FILE_OFFSET_BITS=64 -D__USE_FILE_OFFSET64 -DBOOST_ALL_DYN_LINK -DOPENSSL_NO_KRB5 -I sources/3rdParty/local-config/linux -O3 -DBOOST_NO_CONFIG // LDFLAGS = -ggdb -DNDEBUG -pthread -fPIC -fnon-call-exceptions -DNO_WIN32 -DTCHAR=wchar_t -DUNICODE -D_REENTRANT -D_FILE_OFFSET_BITS=64 -D__USE_FILE_OFFSET64 -DBOOST_ALL_DYN_LINK -DOPENSSL_NO_KRB5 // LIBS = -lrt -lm -lpthread I am using g++ 3.3.3. The above happens even when the first line of test.cpp defines BOOST_REGEX_BUGGY_CTYPE_FACET The release libboost_regex is ~660k in size, whereas the debug is ~5.5M, so I'd really appreciate being able to compile regex in release, and definitely the other boost libraries as well (which don't cause problems and have a similar ratio of release/debug sizes). Any suggestions? Yitzhak Sapir CONFIDENTIALITY CAUTION This e-mail and any attachments may be confidential or legally privileged. If you received this message in error or are not the intended recipient, you should destroy the e-mail message and any attachments or copies, and you are prohibited from retaining, distributing, disclosing or using any information contained herein. Please inform us of the erroneous delivery by return e-mail. Thank you for your cooperation.
g++ -I sources/3rdParty/boost -I sources/3rdParty/local-config/linux/ g++ -Lsources/3rdParty/releases/linux/debug [works] g++ -I sources/3rdParty/boost -I sources/3rdParty/local-config/linux/ g++ -Lsources/3rdParty/releases/linux/release sources/3rdParty/releases/linux/release//libboost_regex.so: undefined reference to 'boost::re_detail::cpp_regex_traits_implementation<char>::isctype(char, unsigned) const'
collect2: ld returned 1 exit status
------------- The above command lines should be:
g++ -I sources/3rdParty/boost -I sources/3rdParty/local-config/linux/ -Lsources/3rdParty/releases/linux/debug -lboost_regex test.cpp [works] g++ -I sources/3rdParty/boost -I sources/3rdParty/local-config/linux/ -Lsources/3rdParty/releases/linux/release -lboost_regex test.cpp [gives above error]
Yitzhak Sapir CONFIDENTIALITY CAUTION This e-mail and any attachments may be confidential or legally privileged. If you received this message in error or are not the intended recipient, you should destroy the e-mail message and any attachments or copies, and you are prohibited from retaining, distributing, disclosing or using any information contained herein. Please inform us of the erroneous delivery by return e-mail. Thank you for your cooperation.
The above command lines should be:
g++ -I sources/3rdParty/boost -I sources/3rdParty/local-config/linux/ g++ -Lsources/3rdParty/releases/linux/debug -lboost_regex test.cpp g++ [works] -I sources/3rdParty/boost -I g++ sources/3rdParty/local-config/linux/ g++ -Lsources/3rdParty/releases/linux/release -lboost_regex test.cpp g++ [gives above error]
I guess my mail program (Outlook) reduplicates the > g++ on every new line when it splits up the lines. Sorry about this. g++ -I sources/3rdParty/boost -I sources/3rdParty/local-config/linux/ -Lsources/3rdParty/releases/linux/debug -lboost_regex test.cpp [works] g++ -I sources/3rdParty/boost -I sources/3rdParty/local-config/linux/ -Lsources/3rdParty/releases/linux/release -lboost_regex test.cpp [gives above error] Yitzhak Sapir CONFIDENTIALITY CAUTION This e-mail and any attachments may be confidential or legally privileged. If you received this message in error or are not the intended recipient, you should destroy the e-mail message and any attachments or copies, and you are prohibited from retaining, distributing, disclosing or using any information contained herein. Please inform us of the erroneous delivery by return e-mail. Thank you for your cooperation.
Yitzhak Sapir wrote:
The above command lines should be:
g++ -I sources/3rdParty/boost -I sources/3rdParty/local-config/linux/ g++ -Lsources/3rdParty/releases/linux/debug -lboost_regex test.cpp g++ [works] -I sources/3rdParty/boost -I g++ sources/3rdParty/local-config/linux/ g++ -Lsources/3rdParty/releases/linux/release -lboost_regex test.cpp g++ [gives above error]
I guess my mail program (Outlook) reduplicates the > g++ on every new line when it splits up the lines. Sorry about this.
g++ -I sources/3rdParty/boost -I sources/3rdParty/local-config/linux/ -Lsources/3rdParty/releases/linux/debug -lboost_regex test.cpp [works]
g++ -I sources/3rdParty/boost -I sources/3rdParty/local-config/linux/ -Lsources/3rdParty/releases/linux/release -lboost_regex test.cpp [gives above error]
Well.... the obvious mistake is that the library name must occur *after* the source file that uses it. Does this help? John.
I guess my mail program (Outlook) reduplicates the > g++ on every new line when it splits up the lines. Sorry about this.
g++ -I sources/3rdParty/boost -I sources/3rdParty/local-config/linux/ -Lsources/3rdParty/releases/linux/debug -lboost_regex test.cpp [works]
g++ -I sources/3rdParty/boost -I sources/3rdParty/local-config/linux/ -Lsources/3rdParty/releases/linux/release -lboost_regex test.cpp [gives above error]
Well.... the obvious mistake is that the library name must occur *after* the source file that uses it.
Does this help?
Not really. The library name must occur after all libraries that use that library (that is, order of decreasing dependency). But in this case I'm compiling a small cpp directly into an a.out. The cpp name is the input to the compiler and should be placed after all options, including the options that g++ is expected to pass to the linker. Your answer further does not explain why the corresponding and similar command line works with the debug version of the library. I have seen problems like this in cases of wrong inline instantiations. I remember a similar problem in Visual Studio with an exported (inline) template function in an exported class, where the client user of the shared library expects to import a function, but obviously the compiler couldn't generate the template function instantiation when creating the dll, and so there is a resulting import of a nonexistent function -- an undefined reference. This seems to be a related problem, except that in g++ 3.3.3 there is no control of export declarations that I know of. In Visual Studio, the problem would be solved by making the class non- exported, and specifying for the specific necessary functions within the class the export declaration. Also, if this were a result of inlining, it would explain why the problem does not appear in debug. Yitzhak Sapir CONFIDENTIALITY CAUTION This e-mail and any attachments may be confidential or legally privileged. If you received this message in error or are not the intended recipient, you should destroy the e-mail message and any attachments or copies, and you are prohibited from retaining, distributing, disclosing or using any information contained herein. Please inform us of the erroneous delivery by return e-mail. Thank you for your cooperation.
Yitzhak Sapir wrote:
that I know of. In Visual Studio, the problem would be solved by making the class non- exported, and specifying for the specific necessary functions within the class the export declaration. Also, if this were a result of inlining, it would explain why the problem does not appear in debug.
I think you're correct that this is an inlining issue: and specific to GCC prior to 3.4 (which is where BOOST_REGEX_BUGGY_CTYPE_FACET is defined). Can you try removing the following section: #ifdef BOOST_REGEX_BUGGY_CTYPE_FACET template BOOST_REGEX_DECL bool cpp_regex_traits_implementation<BOOST_REGEX_CHAR_T>::isctype(const BOOST_REGEX_CHAR_T c, char_class_type mask) const; #endif from instantiate.hpp and then rebuild both the library and the test app and see if that fixes the issue? HTH, John.
that I know of. In Visual Studio, the problem would be solved by making the class non- exported, and specifying for the specific necessary functions within the class the export declaration. Also, if this were a result of inlining, it would explain why the
Yitzhak Sapir wrote: problem does
not appear in debug.
I think you're correct that this is an inlining issue: and specific to GCC prior to 3.4 (which is where BOOST_REGEX_BUGGY_CTYPE_FACET is defined).
Can you try removing the following section:
#ifdef BOOST_REGEX_BUGGY_CTYPE_FACET template BOOST_REGEX_DECL bool cpp_regex_traits_implementation<BOOST_REGEX_CHAR_T>::isctype(const BOOST_REGEX_CHAR_T c, char_class_type mask) const; #endif
from instantiate.hpp and then rebuild both the library and the test app and see if that fixes the issue?
Well, the macro appears in boost/regex/v4/cpp_regex_traits.hpp, boost/regex/v4/instances.hpp, and boost/regex/config.hpp If the #ifdef in instances.hpp is changed to #if 0, I get the following: /tmp/cc7hZEMV.o(.gnu.linkonce.t._ZN5boost11basic_regexIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE6assignEPKcS7_j+0x22): In function `boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::assign(char const*, char const*, unsigned)': : undefined reference to `boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::do_assign(char const*, char const*, unsigned)' collect2: ld returned 1 exit status [ If I also comment out the define of the macro in config.hpp, I still get the same thing: /tmp/ccH7Bese.o(.gnu.linkonce.t._ZN5boost11basic_regexIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE6assignEPKcS7_j+0x22): In function `boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::assign(char const*, char const*, unsigned)': : undefined reference to `boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::do_assign(char const*, char const*, unsigned)' collect2: ld returned 1 exit status Yitzhak Sapir CONFIDENTIALITY CAUTION This e-mail and any attachments may be confidential or legally privileged. If you received this message in error or are not the intended recipient, you should destroy the e-mail message and any attachments or copies, and you are prohibited from retaining, distributing, disclosing or using any information contained herein. Please inform us of the erroneous delivery by return e-mail. Thank you for your cooperation.
Yitzhak Sapir wrote:
If the #ifdef in instances.hpp is changed to #if 0, I get the following: /tmp/cc7hZEMV.o(.gnu.linkonce.t._ZN5boost11basic_regexIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE6assignEPKcS7_j+0x22): In function `boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::assign(char const*, char const*, unsigned)':
undefined reference to `boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> >
::do_assign(char const*, char const*, unsigned)'
collect2: ld returned 1 exit status [ If I also comment out the define of the macro in config.hpp, I still get the same thing: /tmp/ccH7Bese.o(.gnu.linkonce.t._ZN5boost11basic_regexIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE6assignEPKcS7_j+0x22): In function `boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::assign(char const*, char const*, unsigned)': > undefined reference to `boost::basic_regex<char, > boost::regex_traits<char, boost::cpp_regex_traits<char> > > >::do_assign(char const*, char const*, unsigned)' collect2: ld returned 1 exit status
Well I'm rather puzzelled why you're the only person to be experiencing this... I've tried to locate a binary version of gcc-3.3 to test with but couldn't find one for my Linux box - is there any way you can use a newer gcc release as 3.3 is rather old these days? Alternatively what happens if you build the application and the regex source all together like this: g++ -O3 test.cpp boost-path/libs/regex/src/*.cpp or if that fails then like this: g++ -O3 -DBOOST_REGEX_NO_EXTERNAL_TEMPLATES=1 test.cpp boost-path/libs/regex/src/*.cpp ? HTH, John.
Yitzhak Sapir wrote:
If the #ifdef in instances.hpp is changed to #if 0, I get the following:
/tmp/cc7hZEMV.o(.gnu.linkonce.t._ZN5boost11basic_regexIcNS_12r egex_traitsIcNS_16cpp_regex_traitsIcEEEEE6assignEPKcS7_j+0x22):
In function `boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::assign(char const*, char const*, unsigned)':
undefined reference to `boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> >
::do_assign(char const*, char const*, unsigned)'
collect2: ld returned 1 exit status
This is wrong. I guess I must have not passed the library itself when I compiled this. When I now compile it with the above change only (#if 0 instead of #ifdef BOOST_REGEX_BUGGY_CTYPE_FACET in the appropriate line in boost/regex/v4/instances.hpp), the code compiles and links fine. Yitzhak Sapir CONFIDENTIALITY CAUTION This e-mail and any attachments may be confidential or legally privileged. If you received this message in error or are not the intended recipient, you should destroy the e-mail message and any attachments or copies, and you are prohibited from retaining, distributing, disclosing or using any information contained herein. Please inform us of the erroneous delivery by return e-mail. Thank you for your cooperation.
Yitzhak Sapir wrote:
This is wrong. I guess I must have not passed the library itself when I compiled this. When I now compile it with the above change only (#if 0 instead of #ifdef BOOST_REGEX_BUGGY_CTYPE_FACET in the appropriate line in boost/regex/v4/instances.hpp), the code compiles and links fine.
Whew :-) Glad we got to the bottom of that in the end! John.
Colin Caughie <c.caughie <at> indigovision.com> writes:
Hi,
It's a while now since the review of John Torjo's Logging library was
concluded,
and I'm curious to know what the result was. Is it still being considered?
My comp got busted and last couple weeks all my free time I had to invest into building new one. I am almost done now and actively looking through reviews again. The results should be available soon. Gennadiy
participants (4)
-
Colin Caughie -
Gennadiy Rozental -
John Maddock -
Yitzhak Sapir