From: Richard Newman (richard_at_[hidden])
Date: 2005-08-11 13:22:53
When I reduced the test set to the following test, it still hangs but
says that one test passed (as the 48 I used before did).
BOOST_AUTO_UNIT_TEST(TrivialTest)
{
int x = 0;
x = 1;
}
When I remove this one test and so have no tests, no hang occurs. It
simply says no errors and terminates normally. I guess I can review the
macro represented by BOOST_AUTO_UNIT_TEST to see what might be invoked
here.
The make session for both cases was the same (excepting of course the
test output):
--------------------
$ make
if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H
-I. -I/home/<somepath>/project/src/mylibrary -I../..
-I/home/<somepath>/project/src -I/home/<somepath>/construct/dep/include
-D__CSGA_REVISION__='"2057M"' -pthread -Werror -Wall -g -O2 -MT
function.lo -MD -MP -MF ".deps/function.Tpo" -c -o function.lo
function.cpp; \
then mv -f ".deps/function.Tpo" ".deps/function.Plo"; else rm -f
".deps/function.Tpo"; exit 1; fi
g++ -DHAVE_CONFIG_H -I. -I/home/<somepath>/project/src/mylibrary
-I../.. -I/<somepath>/project/src -I/<somepath>/dep/include
-D__CSGA_REVISION__=\"2057M\" -pthread -Werror -Wall -g -O2 -MT
function.lo -MD -MP -MF .deps/function.Tpo -c function.cpp -fPIC -DPIC
-o .libs/function.o
/bin/sh ../../libtool --tag=CXX --mode=link g++ -pthread -Werror -Wall
-g -O2 -o mylibrary.la -rpath /<somepath>/release/product/lib
<several .lo files listed> -L/<somepath>/dep/lib -lxslt -lxml2 -lxmlwrapp
rm -fr .libs/mylibrary.0 .libs/mylibrary.0.0.0 .libs/mylibrary.la
.libs/mylibrary.lai
g++ -shared -nostdlib
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../../crti.o
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/crtbeginS.o
<several .o files listed under .libs/> -L/usr/lib -L/<somepath>/dep/lib
/usr/lib/libxslt.so /usr/lib/libxml2.so -lxmlwrapp
-L/usr/lib/gcc-lib/i386-redhat-linux/3.3.3
-L/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../.. -lstdc++ -lm -lc
-lgcc_s /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/crtendS.o
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../../crtn.o -pthread
-Werror -Wall -g -O2 -Wl,-soname -Wl,mylibrary.0 -o .libs/mylibrary.0.0.0
(cd .libs && rm -f mylibrary.0 && ln -s mylibrary.0.0.0 mylibrary.0)
(cd .libs && rm -f mylibrary && ln -s mylibrary.0.0.0 mylibrary)
creating mylibrary.la
(cd .libs && rm -f mylibrary.la && ln -s ../mylibrary.la mylibrary.la)
/bin/sh ../../libtool --tag=CXX --mode=link g++ -pthread -Werror -Wall
-g -O2 -o mytestsuite -R/<somepath>/dep/lib mytestsuite.o
../../src/mylibrary/mylibrary.la -L/<somepath>/dep/lib
-lboost_unit_test_framework
g++ -pthread -Werror -Wall -g -O2 -o .libs/mytestsuite mytestsuite.o
../../src/mylibrary/.libs/mylibrary -L/<somepath>/dep/lib -L/usr/lib
/usr/lib/libxslt.so /usr/lib/libxml2.so -lm -lpthread -lz -lxmlwrapp
-lboost_unit_test_framework -Wl,--rpath
-Wl,/<somepath>/release/product/lib -Wl,--rpath -Wl,/<somepath>/dep/lib
creating mytestsuite
../../src/mylibrary/mytestsuite
*** No errors detected
--------------------
Richard
Richard Newman wrote:
> I appreciate your reply.
>
> With it coming from an RPM, I think I can only tell if it were linked in
> multi-thread mode by looking at its dependencies (there is no _mt_gcc
> type suffixes on the libraries since they are just copied into /usr/lib
> by the RPM). The dependencies include libpthread, so I'm going to
> assume from that multi-threaded mode has been used to build the
> libraries for the package. When we built Boost directly, we generally
> used the _mt_gcc version.
>
> Nominally, we don't need pthreads right now in our test case as none of
> the tests seem to directly invoke mutexes. However, the library we are
> building the test suite to cover does include mutex support. (We
> recently began to use the Boost test framework to automate unit testing
> and so we have been adding tests as we touch code during refactors, etc.
> so our test coverage is not at all complete yet). In any case, linking
> with pthread on my FC4/gcc4.0.1/boost1.32.0-6rpm worked fine. I do
> think though that a library reference might be to blame, I just don't
> know where to look.
>
> I could certainly do a trivial single test case. However, I had avoided
> such an approach because to compare apples to apples, the best is to
> leave everything in place and comment out all the unit tests, adding
> back in a single one. From there though, I could start to tear apart
> the make files and note when things changed. I'm probably left with
> that as the only real diagnostic now; I was hoping the symptoms were
> indicative of some library, etc., missing that I was ignorant of.
>
> Thanks,
> Richard
>
>
>
> Gennadiy Rozental wrote:
>
>>>Any advice to proceed and repair? We'd like very much to be able to use
>>>these RPMs than reverting back to our previous homegrown approach.
>>
>>
>>I don't think I could be of too much help here. Couple notes though. All
>>boost libraries could be built both in single and multi-thread mode. Could
>>you choose one to use? Which one are you using now? Does it anything to do
>>with what you are doing - Did you try to run trivial single test case
>>module? Why do you need to link with pthreads at all?
>>
>>Gennadiy