[bind10-dev] Which version of gtest should I use whenperformingunit tests?

Mary babyvole at 163.com
Mon Dec 27 02:49:20 UTC 2010


Hi Jeremy,

Here is my experience:

The first time, (1)I used the following values for parameters for 'configure':
./configure --prefix=/home/software/bind10 --with-lcov=/home/software/lcov/usr/bin/lcov --with-gtest=/home/software/gtest --disable-setproctitle-check
(2)Then ran 'make'. No error information at all.
(3)Then./configure --prefix=/home/software/bind10 --with-lcov=/home/software/lcov/usr/bin/lcov --disable-setproctitle-check
(4)when running 'make':
run_unittests-data_unittests.o: In function `(anonymous namespace)::Element_to_and_from_wire_Test::TestBody()':
/home/software/bind10-devel-20101201/src/lib/cc/tests/data_unittests.cc:385: undefined reference to `testing::internal::AssertHelper::AssertHelper(testing::TestPartResultType, char const*, int, char const*)'
/home/software/bind10-devel-20101201/src/lib/cc/tests/data_unittests.cc:386: undefined reference to `testing::internal::AssertHelper::AssertHelper(testing::TestPartResultType, char const*, int, char const*)'
/home/software/bind10-devel-20101201/src/lib/cc/tests/data_unittests.cc:387: undefined reference to `testing::internal::AssertHelper::AssertHelper(testing::TestPartResultType, char const*, int, char const*)'
/home/software/bind10-devel-20101201/src/lib/cc/tests/data_unittests.cc:388: undefined reference to `testing::internal::AssertHelper::AssertHelper(testing::TestPartResultType, char const*, int, char const*)'
/home/software/bind10-devel-20101201/src/lib/cc/tests/data_unittests.cc:389: undefined reference to `testing::internal::AssertHelper::AssertHelper(testing::TestPartResultType, char const*, int, char const*)'
run_unittests-data_unittests.o:/home/software/bind10-devel-20101201/src/lib/cc/tests/data_unittests.cc:390: more undefined references to `testing::internal::AssertHelper::AssertHelper(testing::TestPartResultType, char const*, int, char const*)' follow
collect2: ld returned 1 exit status
make[6]: *** [run_unittests] Error 1
make[6]: Leaving directory `/home/software/bind10-devel-20101201/src/lib/cc/tests'
make[5]: *** [all-recursive] Error 1
make[5]: Leaving directory `/home/software/bind10-devel-20101201/src/lib/cc'
make[4]: *** [all] Error 2
make[4]: Leaving directory `/home/software/bind10-devel-20101201/src/lib/cc'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/software/bind10-devel-20101201/src/lib'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/software/bind10-devel-20101201/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/software/bind10-devel-20101201'
make: *** [all] Error 2

======================================================
The second time, I used the same values for parameters for configure:
configure with some values
make
make clean
configure with other values
make
All is OK.

I think it does no harm that bind10 can run 'make clean' automatically when the 'configure' statement has changed.^_^



>On Mon, 20 Dec 2010, Mary wrote:
>
>> BTW: I'd strongly recommend that a 'make clean' command should be 
>> executed automatically when necessary( e.g. the parameters for 
>> configure have changed?. I've heard that bind 9.7 does something like 
>> this in 'configure'
>
>Can you share a specific example (maybe copy and paste error output) of 
>why you think this is needed?
>
>We probably should fix case-by-case make issues versus starting 
>over.
>
>  Jeremy C. Reed
>  ISC
= = = = = = = = = = = = = = = = = = = =
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20101227/843b181c/attachment.html>


More information about the bind10-dev mailing list