Re: Build failed in Hudson: 3.HEAD-i386-OpenBSD #553

On 09/09/2010 09:56 AM, Kinkie wrote:
>> /bin/sh ../libtool --tag=CXX --mode=link ccache g++ -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2 -g -o testPreCompiler testPreCompiler.o testMain.o -L/usr/local/lib -lcppunit
>> libtool: link: ccache g++ -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2 -g -o testPreCompiler testPreCompiler.o testMain.o -L/usr/local/lib -lcppunit -lm -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr/local/lib
>> /usr/local/lib/libestdc++.so.11.0: warning: vsprintf() is often misused, please use vsnprintf()
>> /usr/local/lib/libcppunit.so.3.0: warning: strcpy() is almost always misused, please use strlcpy()
>> /usr/local/lib/libcppunit.so.3.0: warning: strcat() is almost always misused, please use strlcat()
>> /usr/local/lib/libcppunit.so.3.0: warning: sprintf() is often misused, please use snprintf()
>> /usr/local/lib/libcppunit.so.3.0: undefined reference to `std::basic_streambuf<char, std::char_traits<char> >::_M_out_cur_move(long)'
>> /usr/local/lib/libcppunit.so.3.0: undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Rep::_S_create(unsigned long, std::allocator<char> const&)'
>> /usr/local/lib/libcppunit.so.3.0: undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_empty_rep_storage'
>> /usr/local/lib/libcppunit.so.3.0: undefined reference to `std::__default_alloc_template<true, 0>::deallocate(void*, unsigned long)'
>> /usr/local/lib/libcppunit.so.3.0: undefined reference to `std::__default_alloc_template<true, 0>::allocate(unsigned long)'
>> collect2: ld returned 1 exit status
>> *** Error code 1
>>
>
> g++ 3.3.5 on OpenBsd segfaults on the new HttpParser, I've tried
> updating to 4.4.2 (IIRC).
> Alex, what do you think? Is this fixable or should I revert to 3.3.5?

I am sure it is fixable even though I do not know what is wrong. I would
recommend starting by splitting the
testHttpRequest::testParseRequestLine() monster code into independent
parts, all called from testHttpRequest::testParseRequestLine(). That
could do it. If that does not help, we would at least localize the
problem somewhat.

Empty lines in testHttpRequest::testParseRequestLine may guide you to
the right part boundaries.

HTH,

Alex.
Received on Fri Sep 10 2010 - 17:44:05 MDT