levinj / googletest Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/googletest
License: BSD 3-Clause "New" or "Revised" License
Automatically exported from code.google.com/p/googletest
License: BSD 3-Clause "New" or "Revised" License
Google C++ Testing Framework ============================ http://code.google.com/p/googletest/ Overview -------- Google's framework for writing C++ tests on a variety of platforms (Linux, Mac OS X, Windows, Windows CE, Symbian, etc). Based on the xUnit architecture. Supports automatic test discovery, a rich set of assertions, user-defined assertions, death tests, fatal and non-fatal failures, various options for running the tests, and XML test report generation. Please see the project page above for more information as well as the mailing list for questions, discussions, and development. There is also an IRC channel on OFTC (irc.oftc.net) #gtest available. Please join us! Requirements for End Users -------------------------- Google Test is designed to have fairly minimal requirements to build and use with your projects, but there are some. Currently, we support Linux, Windows, Mac OS X, and Cygwin. We will also make our best effort to support other platforms (e.g. Solaris, AIX, and z/OS). However, since core members of the Google Test project have no access to these platforms, Google Test may have outstanding issues there. If you notice any problems on your platform, please notify [email protected]. Patches for fixing them are even more welcome! ### Linux Requirements ### These are the base requirements to build and use Google Test from a source package (as described below): * GNU-compatible Make or gmake * POSIX-standard shell * POSIX(-2) Regular Expressions (regex.h) * A C++98-standard-compliant compiler ### Windows Requirements ### * Microsoft Visual C++ 7.1 or newer ### Cygwin Requirements ### * Cygwin 1.5.25-14 or newer ### Mac OS X Requirements ### * Mac OS X 10.4 Tiger or newer * Developer Tools Installed Also, you'll need CMake 2.6.4 or higher if you want to build the samples using the provided CMake script, regardless of the platform. Requirements for Contributors ----------------------------- We welcome patches. If you plan to contribute a patch, you need to build Google Test and its own tests from an SVN checkout (described below), which has further requirements: * Python version 2.3 or newer (for running some of the tests and re-generating certain source files from templates) * CMake 2.6.4 or newer Getting the Source ------------------ There are two primary ways of getting Google Test's source code: you can download a stable source release in your preferred archive format, or directly check out the source from our Subversion (SVN) repository. The SVN checkout requires a few extra steps and some extra software packages on your system, but lets you track the latest development and make patches much more easily, so we highly encourage it. ### Source Package ### Google Test is released in versioned source packages which can be downloaded from the download page [1]. Several different archive formats are provided, but the only difference is the tools used to manipulate them, and the size of the resulting file. Download whichever you are most comfortable with. [1] http://code.google.com/p/googletest/downloads/list Once the package is downloaded, expand it using whichever tools you prefer for that type. This will result in a new directory with the name "gtest-X.Y.Z" which contains all of the source code. Here are some examples on Linux: tar -xvzf gtest-X.Y.Z.tar.gz tar -xvjf gtest-X.Y.Z.tar.bz2 unzip gtest-X.Y.Z.zip ### SVN Checkout ### To check out the main branch (also known as the "trunk") of Google Test, run the following Subversion command: svn checkout http://googletest.googlecode.com/svn/trunk/ gtest-svn Setting up the Build -------------------- To build Google Test and your tests that use it, you need to tell your build system where to find its headers and source files. The exact way to do it depends on which build system you use, and is usually straightforward. ### Generic Build Instructions ### Suppose you put Google Test in directory ${GTEST_DIR}. To build it, create a library build target (or a project as called by Visual Studio and Xcode) to compile ${GTEST_DIR}/src/gtest-all.cc with ${GTEST_DIR}/include in the system header search path and ${GTEST_DIR} in the normal header search path. Assuming a Linux-like system and gcc, something like the following will do: g++ -isystem ${GTEST_DIR}/include -I${GTEST_DIR} \ -pthread -c ${GTEST_DIR}/src/gtest-all.cc ar -rv libgtest.a gtest-all.o (We need -pthread as Google Test uses threads.) Next, you should compile your test source file with ${GTEST_DIR}/include in the system header search path, and link it with gtest and any other necessary libraries: g++ -isystem ${GTEST_DIR}/include -pthread path/to/your_test.cc libgtest.a \ -o your_test As an example, the make/ directory contains a Makefile that you can use to build Google Test on systems where GNU make is available (e.g. Linux, Mac OS X, and Cygwin). It doesn't try to build Google Test's own tests. Instead, it just builds the Google Test library and a sample test. You can use it as a starting point for your own build script. If the default settings are correct for your environment, the following commands should succeed: cd ${GTEST_DIR}/make make ./sample1_unittest If you see errors, try to tweak the contents of make/Makefile to make them go away. There are instructions in make/Makefile on how to do it. ### Using CMake ### Google Test comes with a CMake build script (CMakeLists.txt) that can be used on a wide range of platforms ("C" stands for cross-platform.). If you don't have CMake installed already, you can download it for free from http://www.cmake.org/. CMake works by generating native makefiles or build projects that can be used in the compiler environment of your choice. The typical workflow starts with: mkdir mybuild # Create a directory to hold the build output. cd mybuild cmake ${GTEST_DIR} # Generate native build scripts. If you want to build Google Test's samples, you should replace the last command with cmake -Dgtest_build_samples=ON ${GTEST_DIR} If you are on a *nix system, you should now see a Makefile in the current directory. Just type 'make' to build gtest. If you use Windows and have Visual Studio installed, a gtest.sln file and several .vcproj files will be created. You can then build them using Visual Studio. On Mac OS X with Xcode installed, a .xcodeproj file will be generated. ### Legacy Build Scripts ### Before settling on CMake, we have been providing hand-maintained build projects/scripts for Visual Studio, Xcode, and Autotools. While we continue to provide them for convenience, they are not actively maintained any more. We highly recommend that you follow the instructions in the previous two sections to integrate Google Test with your existing build system. If you still need to use the legacy build scripts, here's how: The msvc\ folder contains two solutions with Visual C++ projects. Open the gtest.sln or gtest-md.sln file using Visual Studio, and you are ready to build Google Test the same way you build any Visual Studio project. Files that have names ending with -md use DLL versions of Microsoft runtime libraries (the /MD or the /MDd compiler option). Files without that suffix use static versions of the runtime libraries (the /MT or the /MTd option). Please note that one must use the same option to compile both gtest and the test code. If you use Visual Studio 2005 or above, we recommend the -md version as /MD is the default for new projects in these versions of Visual Studio. On Mac OS X, open the gtest.xcodeproj in the xcode/ folder using Xcode. Build the "gtest" target. The universal binary framework will end up in your selected build directory (selected in the Xcode "Preferences..." -> "Building" pane and defaults to xcode/build). Alternatively, at the command line, enter: xcodebuild This will build the "Release" configuration of gtest.framework in your default build location. See the "xcodebuild" man page for more information about building different configurations and building in different locations. If you wish to use the Google Test Xcode project with Xcode 4.x and above, you need to either: * update the SDK configuration options in xcode/Config/General.xconfig. Comment options SDKROOT, MACOS_DEPLOYMENT_TARGET, and GCC_VERSION. If you choose this route you lose the ability to target earlier versions of MacOS X. * Install an SDK for an earlier version. This doesn't appear to be supported by Apple, but has been reported to work (http://stackoverflow.com/questions/5378518). Tweaking Google Test -------------------- Google Test can be used in diverse environments. The default configuration may not work (or may not work well) out of the box in some environments. However, you can easily tweak Google Test by defining control macros on the compiler command line. Generally, these macros are named like GTEST_XYZ and you define them to either 1 or 0 to enable or disable a certain feature. We list the most frequently used macros below. For a complete list, see file include/gtest/internal/gtest-port.h. ### Choosing a TR1 Tuple Library ### Some Google Test features require the C++ Technical Report 1 (TR1) tuple library, which is not yet available with all compilers. The good news is that Google Test implements a subset of TR1 tuple that's enough for its own need, and will automatically use this when the compiler doesn't provide TR1 tuple. Usually you don't need to care about which tuple library Google Test uses. However, if your project already uses TR1 tuple, you need to tell Google Test to use the same TR1 tuple library the rest of your project uses, or the two tuple implementations will clash. To do that, add -DGTEST_USE_OWN_TR1_TUPLE=0 to the compiler flags while compiling Google Test and your tests. If you want to force Google Test to use its own tuple library, just add -DGTEST_USE_OWN_TR1_TUPLE=1 to the compiler flags instead. If you don't want Google Test to use tuple at all, add -DGTEST_HAS_TR1_TUPLE=0 and all features using tuple will be disabled. ### Multi-threaded Tests ### Google Test is thread-safe where the pthread library is available. After #include "gtest/gtest.h", you can check the GTEST_IS_THREADSAFE macro to see whether this is the case (yes if the macro is #defined to 1, no if it's undefined.). If Google Test doesn't correctly detect whether pthread is available in your environment, you can force it with -DGTEST_HAS_PTHREAD=1 or -DGTEST_HAS_PTHREAD=0 When Google Test uses pthread, you may need to add flags to your compiler and/or linker to select the pthread library, or you'll get link errors. If you use the CMake script or the deprecated Autotools script, this is taken care of for you. If you use your own build script, you'll need to read your compiler and linker's manual to figure out what flags to add. ### As a Shared Library (DLL) ### Google Test is compact, so most users can build and link it as a static library for the simplicity. You can choose to use Google Test as a shared library (known as a DLL on Windows) if you prefer. To compile *gtest* as a shared library, add -DGTEST_CREATE_SHARED_LIBRARY=1 to the compiler flags. You'll also need to tell the linker to produce a shared library instead - consult your linker's manual for how to do it. To compile your *tests* that use the gtest shared library, add -DGTEST_LINKED_AS_SHARED_LIBRARY=1 to the compiler flags. Note: while the above steps aren't technically necessary today when using some compilers (e.g. GCC), they may become necessary in the future, if we decide to improve the speed of loading the library (see http://gcc.gnu.org/wiki/Visibility for details). Therefore you are recommended to always add the above flags when using Google Test as a shared library. Otherwise a future release of Google Test may break your build script. ### Avoiding Macro Name Clashes ### In C++, macros don't obey namespaces. Therefore two libraries that both define a macro of the same name will clash if you #include both definitions. In case a Google Test macro clashes with another library, you can force Google Test to rename its macro to avoid the conflict. Specifically, if both Google Test and some other code define macro FOO, you can add -DGTEST_DONT_DEFINE_FOO=1 to the compiler flags to tell Google Test to change the macro's name from FOO to GTEST_FOO. Currently FOO can be FAIL, SUCCEED, or TEST. For example, with -DGTEST_DONT_DEFINE_TEST=1, you'll need to write GTEST_TEST(SomeTest, DoesThis) { ... } instead of TEST(SomeTest, DoesThis) { ... } in order to define a test. Upgrating from an Earlier Version --------------------------------- We strive to keep Google Test releases backward compatible. Sometimes, though, we have to make some breaking changes for the users' long-term benefits. This section describes what you'll need to do if you are upgrading from an earlier version of Google Test. ### Upgrading from 1.3.0 or Earlier ### You may need to explicitly enable or disable Google Test's own TR1 tuple library. See the instructions in section "Choosing a TR1 Tuple Library". ### Upgrading from 1.4.0 or Earlier ### The Autotools build script (configure + make) is no longer officially supportted. You are encouraged to migrate to your own build system or use CMake. If you still need to use Autotools, you can find instructions in the README file from Google Test 1.4.0. On platforms where the pthread library is available, Google Test uses it in order to be thread-safe. See the "Multi-threaded Tests" section for what this means to your build script. If you use Microsoft Visual C++ 7.1 with exceptions disabled, Google Test will no longer compile. This should affect very few people, as a large portion of STL (including <string>) doesn't compile in this mode anyway. We decided to stop supporting it in order to greatly simplify Google Test's implementation. Developing Google Test ---------------------- This section discusses how to make your own changes to Google Test. ### Testing Google Test Itself ### To make sure your changes work as intended and don't break existing functionality, you'll want to compile and run Google Test's own tests. For that you can use CMake: mkdir mybuild cd mybuild cmake -Dgtest_build_tests=ON ${GTEST_DIR} Make sure you have Python installed, as some of Google Test's tests are written in Python. If the cmake command complains about not being able to find Python ("Could NOT find PythonInterp (missing: PYTHON_EXECUTABLE)"), try telling it explicitly where your Python executable can be found: cmake -DPYTHON_EXECUTABLE=path/to/python -Dgtest_build_tests=ON ${GTEST_DIR} Next, you can build Google Test and all of its own tests. On *nix, this is usually done by 'make'. To run the tests, do make test All tests should pass. ### Regenerating Source Files ### Some of Google Test's source files are generated from templates (not in the C++ sense) using a script. A template file is named FOO.pump, where FOO is the name of the file it will generate. For example, the file include/gtest/internal/gtest-type-util.h.pump is used to generate gtest-type-util.h in the same directory. Normally you don't need to worry about regenerating the source files, unless you need to modify them. In that case, you should modify the corresponding .pump files instead and run the pump.py Python script to regenerate them. You can find pump.py in the scripts/ directory. Read the Pump manual [2] for how to use it. [2] http://code.google.com/p/googletest/wiki/PumpManual ### Contributing a Patch ### We welcome patches. Please read the Google Test developer's guide [3] for how you can contribute. In particular, make sure you have signed the Contributor License Agreement, or we won't be able to accept the patch. [3] http://code.google.com/p/googletest/wiki/GoogleTestDevGuide Happy testing!
Thread-safe death tests currently don't search the PATH when re-executing
the test program. This means the user cannot put a test binary that
contains thread-safe death tests in a directory in the PATH and invoke it
without a directory prefix.
This is rarely a problem in practice (hence the low priority), as:
- people rarely leave tests in PATH - that's arguably not a good idea.
- more people use the "fast" style death tests, which don't have this problem.
Just for future reference, Mike Burrows suggested the following
impelementation:
In the forked process, you may not call getenv() (which execvp does,
for example),
and you may not call malloc(), but you can do these things before forking.
Below is an untested example.
Mike
#include <unistd.h>
/* exec() the first file possible that is called name[] and is on the colon
separated path path[], with the argument in argv[].
The path is ignored if name[] contains a slash.
Requires that buffer[] be a scratch area large enough for the longest
pathname generated: a conservative size for buffer[] is
strlen (name) + strlen (path) + 2
Does not return on success.
Example:
const char *path = getenv ("PATH");
char *buffer;
int pid;
if (path == 0) {
path = "/bin:/usr/bin";
}
buffer = malloc (strlen (path) + strlen (name) + 2);
pid = fork ();
if (pid == 0) {
exec_first_on_path (name, path, buffer, argv);
perror (name);
_exit (2);
}
...
*/
void exec_first_on_path (const char *name, const char *path, char
*buffer, char *argv[]) {
if (strchr (name, '/') != 0) {
path = "";
}
path--; /* pretend path has a leading colon
that's never touched */
do {
char *p;
path++; /* skip colon */
for (p = buffer; *path != 0 && *path != ':'; *p++ = *path++) {
}
if (p != buffer) {
*p++ = '/';
}
strcpy (p, name);
execv (buffer, argv);
} while (*path == ':');
}
Original issue reported on code.google.com by [email protected]
on 10 Sep 2008 at 6:24
Such information is available in the XML report but not in the text output.
We should add a --gtest_print_time flag for including timing info in the
text output.
Original issue reported on code.google.com by [email protected]
on 8 Jul 2008 at 6:38
We need to implement functions to capture statndard/error output to
facilitate testing of code sending information there. Suggested names:
void CaptureTestStdout() - starts interception of text output to standard
output
string GetCapturedTestStdout() - terminates stdout capture and returns
captured text in a string
void CaptureTestStderr() - starts interception of text output to standard
error output
string GetCapturedTestStderr() - terminates stderr capture and returns
captured text in a string
Original issue reported on code.google.com by vladlosev
on 23 Jul 2008 at 6:31
This would help with creating 'configure' scripts using autoconf tools.
In particular, the macro 'AC_CHECK_LIB' requires the name of an exported
function. This function is used to check that the library is available and
can be linked. The function can be very simple, and serves only as a
public identifier for checking linkage.
For example:
extern "C" char const* gtest_version_cstr()
{
static char const msg[] = "googletest 1.0.0";
return msg;
}
Then, in 'configure.ac':
AC_CHECK_LIB( [gtest], [gtest_version_cstr] )
Original issue reported on code.google.com by [email protected]
on 8 Jul 2008 at 7:36
The user doesn't expect that failures from other threads may change the
result of EXPECT_{,NON}FATAL_FAILURE.
We also want to be consistent with how EXPECT_NO_FATAL_FAILURE handles
failures from other threads.
http://code.google.com/p/googletest/issues/detail?id=23
Original issue reported on code.google.com by [email protected]
on 1 Oct 2008 at 5:28
Exception testing macros would be useful for many people, especially on
Windows where hard to avoid exceptions.
Required macros:
EXPECT_THROW(Expression, ExpectedExceptionType)
ASSERT_THROW(Expression, ExpectedExceptionType)
EXPECT_NO_THROW(Expression)
ASSERT_NO_THROW(Expression)
Where *_THROW asserts that the given expression throws an exception of
the specified type, while *_NO_THROW asserts that the given expression
does not throw any exception at all.
Original issue reported on code.google.com by [email protected]
on 16 Jul 2008 at 7:52
What steps will reproduce the problem?
1. Download gtest
2. Follow steps to upgrade solution/projects to VS2008
3. Create a new console application in VS2008
4. Add references to the gtest library/include files
5. Add the statement to run all google tests.
Instead of a successful build, you may receive a LNK2005 error in VS2008.
This happened to me as I was attempting to adopt Google test for our MFC-
based project. I was able to solve the problem and wanted to post it here
for others.
The following article provides additional information on LNK2005 errors.
http://cubicspot.blogspot.com/2007/06/solving-pesky-lnk2005-errors.html
Option #2 fixed my issue. In "Properties..." under "C++->Code Generation-
>Runtime Library" Multi-threaded(/MT) was selected for the Release build
and Multi-Threaded Debug (/MTd) was selected for the Debug build. My
project was set to Multi-threaded DLL (/MD) and Multi-threaded Debug DLL
(/MDd) respectively. Any mismatch has the potential to cause this error.
I am not an expert on the subject by any means, but wanted to provide what
I know for others that may experience the issue.
Original issue reported on code.google.com by [email protected]
on 5 Sep 2008 at 7:26
On Fri, Sep 12, 2008 at 3:12 PM, balazs.dan <[email protected]> wrote:
>
> Hello guys,
>
> I've run gtest_unittest on a Hungarian Windows and these tests failed:
> EXPECT_HRESULT_SUCCEEDED
> ASSERT_HRESULT_SUCCEEDED
> EXPECT_HRESULT_FAILED
> ASSERT_HRESULT_FAILED
> The reason is gtest_unittest tests error messages also and these
> messages are localized on windows.
>
> I'm not sure it is a real issue or not, but better to know this
> thing..
Thanks for the report! I believe this only indicates that the tests
aren't portable, and the assertions themselves should be sound. The
tests for the error messages aren't really critical,and it would be
too much hassle to localize them, so I think we'll just disable these
tests.
Original issue reported on code.google.com by [email protected]
on 12 Sep 2008 at 10:30
gtest needs a univeral binary framework for Mac OS X. I propose adding an Xcode
project to build
the framework.
Original issue reported on code.google.com by [email protected]
on 17 Jul 2008 at 9:55
What steps will reproduce the problem?
1. Compilation of unit tests
2.
3.
What is the expected output? What do you see instead?
During linking the following error occurred.
$ make check
...
g++ -g -O2 -o samples/.libs/sample1_unittest samples/sample1_unittest.o
-L/home/emst/gtest-1.0.1/lib/.libs -Llib/.libs -lgtest_main -lgtest
-L/home/mape/downloads/gcc-3.4.4/powerpc-ibm-aix5.2.0.0/libstdc++-v3/src
-L/home/mape/downloads/gcc-3.4.4/powerpc-ibm-aix5.2.0.0/libstdc++-v3/src/.libs
-L/home/mape/downloads/gcc-3.4.4/gcc -L/usr/local/lib
samples/.libs/libsamples.a
-Wl,-blibpath:/usr/local//lib:/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.4:/u
sr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.4/../../..:/usr/lib:/lib
ld: 0711-317 ERROR: Undefined symbol: typeinfo for testing::Test
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: ld returned 8 exit status
make[1]: *** [samples/sample1_unittest] Fel 1
make[1]: Leaving directory `/home/emst/gtest-1.0.1'
make: *** [check-am] Fel 2
What version of the product are you using? On what operating system?
gtest-1.0.1
[emst@aix1 gtest-1.0.1]$ uname -a
AIX aix1 2 5 0056687F4C00
[emst@aix1 gtest-1.0.1]$ gcc --version
gcc (GCC) 3.4.4
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Please provide any additional information below.
From my understanding this is related to virtual functions and some entries
in the vnode table not being generated due to non implemented virtual
functions. But we tried to add an empty body to all virtual functions in
testing::Test but it didn't make a difference.
We later found a workaround that is to compile the unit tests with the flag
-fno-rtti for GCC. After that the linking goes fine and the tests can be run.
Original issue reported on code.google.com by [email protected]
on 27 Aug 2008 at 7:05
In the implementation the 3 macros are somehow used interchangeably. We
should review each use of them and pick the right one:
GTEST_OS_WINODWS for the Windows OS.
_WIN32 for the WIN32 API.
_MSC_VER for the MSVC compiler.
Original issue reported on code.google.com by [email protected]
on 17 Sep 2008 at 6:58
Currently they use strcasecmp which is defined only for POSIX (or C) locale
in POSIX standard. We need consistent behavior across platforms to test for
internationalized code. strcoll might be appropriate to use.
Original issue reported on code.google.com by vladlosev
on 30 Jun 2008 at 8:21
GoogleTestPrimer talks about how to write the main() function, but it fails
to mention that Googletest provides an appropriate version of main in its
gtest_main project.
Original issue reported on code.google.com by vladlosev
on 20 Jul 2008 at 8:09
What steps will reproduce the problem?
1. write a test that throws an exception
2. build and run the test on mac and other platforms (mingw/cygwin on windows)
3. exception crashes the test app so no other tests are run or reported
What is the expected output?
[ RUN ] ExceptionsAsErrors.TestThrowsInt
../test/test_exceptions.cc:12: Failure. Exception of type 'int'
thrown by test.
(Ideally, print name of exception type,
the "what()" string if it is a
subclass of std::exception, and a stack crawl.)
[ FAILED ] ExceptionsAsErrors.TestThrowsInt
What do you see instead?
[ RUN ] ExceptionsAsErrors.TestThrowsInt
terminate called after throwing an instance of 'int'
make[1]: *** [run-tests] Abort trap
make: *** [all] Error 2
Please use labels and text to provide additional information.
this is release 1.1 of gTest
Original issue reported on code.google.com by [email protected]
on 3 Oct 2008 at 9:03
If you have:
class Exception { };
void foo(void) { throw new Exception(); }
EXPECT_THROW(foo(), Exception);
The report will say that Exception was not thrown. This is because the
GTEST_TEST_THROW only catches "expected_exception const&" instead of also
considering "expected_exception const*".
It may be bad style to throw a pointer to an exception, but there's a lot
of legacy code out there that uses "throw new Exception()" instead of
simply "throw Exception()".
The following patch fixes this, and prevents a memory leak in the case of
pointers to exception.
====
//depot/agent/main/ThirdPartySource/gtest/1.1.0/include/gtest/internal/gtest-int
ernal.h#1
-
C:\depot\agent\main\ThirdPartySource\gtest\1.1.0\include\gtest\internal\gtest-in
ternal.h
====
@@ -728,6 +728,10 @@
catch (expected_exception const&) { \
gtest_caught_expected = true; \
} \
+ catch (expected_exception const* expected_exception_const_pointer) { \
+ delete expected_exception_const_pointer;
+ gtest_caught_expected = true; \
+ } \
catch (...) { \
gtest_msg = "Expected: " #statement " throws an exception of type " \
#expected_exception ".\n Actual: it throws a different " \
Original issue reported on code.google.com by [email protected]
on 7 Oct 2008 at 5:45
Instead of hardcoding the name as gtest.lib. This reduces errors and
minimizes changes in case we rename a project.
Original issue reported on code.google.com by vladlosev
on 15 Jul 2008 at 6:07
What steps will reproduce the problem?
1. compile sample2.cc with Visual Studio 2005
Output from compiler is:
cc(52) : warning C4996: 'strcpy' was declared deprecated
c:\program files\microsoft visual studio 8\vc\include\string.h(73) : see declaration of 'strcpy'
Message: 'This function or variable may be unsafe. Consider using strcpy_s instead. To disable
deprecation, use _CRT_SECURE_NO_DEPRECATE. See online help for details.'
I don't want to have to #define _CRT_SECURE_NO_DEPRECATE
Original issue reported on code.google.com by [email protected]
on 6 Oct 2008 at 6:22
Attachments:
Macros don't respect namespaces, so it is sometimes hard for a user to tell
whether a Google Test macro is public or not.
To reduce the likelihood of a user accidentally depend on Google Test's
internal implementation, we should name all internal macros *_ (i.e. ending
with an underscore).
Original issue reported on code.google.com by [email protected]
on 2 Jul 2008 at 7:26
andy.bache _at_ googlemail.com suggested:
"I have just got started with Google C++ Testing Framework and was
wondering if anyone had built or is planning to build a Google C++
Tests Add In for Visual Studio. I have used the NUnit add in with the
#Develop IDE. It runs all the tests as part of build process and
displays the results on a panel within the IDE.
I have been away from C++ for a little while and have just returned to
developing in C++ with Visual Studio and am trying to get a Unit Test
framework in place. I like the look of google tests but having it
better integrated with the IDE would be helpful.
Using the post build step to kick off unit tests is a good start but
it would be better to have the results integrated in the IDE.
I guess that I could write my own Visual Studio Add In - possibly
parsing the XML results file and displaying the results in the IDE but
I have never written on before so that would quite a bit of time and
effort and I would hate to do it if someone else already has and made
a good job of it.
If you know of anything like this or also think it would be useful get
back to me.
Cheers,"
I replied:
"Hi Andy,
Thanks for the suggestion! I think this will be something very nice to
have.
Unfortunately I don't know how to write a VS add-in either, and my
hands are full (actually more than full). Therefore I hope you or
someone interested could take the challenge to implement it and share
the result with the rest of us. Cheers!"
Original issue reported on code.google.com by [email protected]
on 29 Sep 2008 at 3:14
Google Test's XML report format differs from JUnit's slightly. While we
cannot change it without breaking some existing processes, a quick
short-term solution is to write an XSLT to convert
Google Test's output to JUnit's format (it's also very flexible in
case JUnit changes its format). In the long run, we could extend the
--gtest_output flag with an option to use the JUnit format, e.g.
--gtest_output=junit_xml
instead of
--gtest_output=xml
This will be more work to implement but is easier for the users.
Original issue reported on code.google.com by [email protected]
on 8 Sep 2008 at 7:20
What steps will reproduce the problem?
1.
main.cpp
--------
bool ThrowAnException()
{
throw 0;
}
TEST(Test, Exception)
{
EXPECT_TRUE(ThrowAnException());
}
../main.cpp
-----------
int main(int argc, char **argv) {
std::cout << "Running main() from gtest_main.cc\n";
testing::InitGoogleTest(&argc, argv);
return RUN_ALL_TESTS();
}
2. g++ -o main main.cpp ../main.cpp ../lib/libgtest.a -I../include
3. ./main
What is the expected output? What do you see instead?
I expected the same as in Issue 16.
~/tests/test$ ./main
Running main() from gtest_main.cc
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from Test
[ RUN ] Test.Exception
terminate called after throwing an instance of 'int'
Aborted
What version of the product are you using? On what operating system?
Just checked out the svn trunk at a Debian GNU/Linux
Please provide any additional information below.
It happened to me while testing googletest in another project but I
simplified to this
Original issue reported on code.google.com by [email protected]
on 21 Aug 2008 at 8:08
Requirements section in README file
(http://code.google.com/p/googletest/source/browse/trunk/README) doesn't
list requirements for building gtest under Cygwin. The necessary packages
include:
* libtool, automake, and autoconf for configuring builds out of svn
* gcc, make, and python for building gtest
Currently, the README file lists only Cygwin version required for building.
Original issue reported on code.google.com by vladlosev
on 15 Jul 2008 at 5:56
What steps will reproduce the problem?
1. Create a failing test
2. Run the test in Microsoft Visual Studio
What is the expected output?
unittest.cc(107): error: Value of: false
Actual: false
Expected: true
What do you see instead?
unittest.cc:107: Failure
Value of: GTEST_IS_NULL_LITERAL(1)
Actual: false
Expected: true
What version of the product are you using? On what operating system?
1.0.0
Windows
Visual Studio 2005
Please provide any additional information below.
Currently the PrettyUnitTestResultPrinter prints failures in this
format: "FILE:LINE: Failure", while MSVC expects this format:
"FILE(LINE): error: ..."!
I've created a patch which uses the correct format iff _MSC_VER defined.
Original issue reported on code.google.com by [email protected]
on 9 Jul 2008 at 2:50
Attachments:
hello!
What steps will reproduce the problem?
1.I used vs2005 build a vc project. The project static-link 'gtest.lib' ,
when i compiler , IDE prompt many link-errors( like : "error
LNK2005: "public: __thiscall std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char>
>::~basic_string<char,struct std::char_traits<char>,class
std::allocator<char> >(void)" (??1?$basic_string@DU?$char_traits@D@std@@V?
$allocator@D@2@@std@@QAE@XZ) has defined in msvcprtd.lib(MSVCP80D.dll)"
What version of the product are you using? On what operating system?
1.0.1
thanks;
Original issue reported on code.google.com by [email protected]
on 22 Jul 2008 at 8:44
The GoogleTestAdvancedGuide page in the wiki documents an environment
variable / command line switch to cause test timings to be printed.
This switch is not implemented in the Google Test library.
It would be useful to have.
Original issue reported on code.google.com by [email protected]
on 17 Aug 2008 at 4:35
src/gtest-filepath.cc: In static member function 'static
testing::internal::FilePath testing::internal::FilePath::GetCurrentDir()':
src/gtest-filepath.cc:82: error: 'PATH_MAX' was not declared in this scope
src/gtest-filepath.cc:83: error: 'cwd' was not declared in this scope
make: *** [src/gtest-filepath.lo] Error 1
I added #include <limits.h>, which fixed the problem.
Original issue reported on code.google.com by [email protected]
on 30 Sep 2008 at 5:42
Currently, our users have to type the following command after downloading
the source from svn:
aclocal && libtoolize -c && autoheader && automake -ac && autoconf
(aclocal >= 1.9 && automake >= 1.9)
We should provide a script to perform this sequence.
Original issue reported on code.google.com by vladlosev
on 15 Jul 2008 at 6:02
There doesn't seem to be good memory leak detection (or any at all).
What would be nice is if there's a way to save the heap and stack memory
address before the test, and then compare the heap and stack memory
addresses after end of the test fixture and check for any memory leaks.
This doesn't seem to be happening.
Original issue reported on code.google.com by [email protected]
on 17 Jul 2008 at 8:35
Some GTEST_* macros have two states: defined vs undefined, e.g.
GTEST_OS_MAC. Some GTEST_* macros have either 0 or 1 values, e.g.
GTEST_IS_THREADSAFE. Try to use the same convention across the board.
Original issue reported on code.google.com by [email protected]
on 11 Oct 2008 at 6:52
Google Test doesn't depend on exceptions, so the ASSERT_* macros will
return from the current function when they failed. This is all right
normally. However, if your test calls a sub-routine that has an
ASSERT_* failure in it, your test will continue after the sub-routine
returns. This may not be what you want.
To solve this, you can write
Foo(); // This may generate an ASSERT_* failure.
if (HasFatalFailure()) return;
where HasFatalFailure() is a static method of Google Test's
testing::Test class. However this doesn't tell you which sub-routine
caused the problem when you call multiple of them in the same test.
After discussions with Googlers Bob Sidebotham and Matt Frantz, I'd
like to propose the following macro (the idea is mostly theirs):
ASSERT_NO_FATAL_FAILURE(statement);
will execute 'statement' and assert that it doesn't generate any *new*
ASSERT_* failures. If it does, Google Test will print a failure
message with the source text of 'statement' in it, and return from the
current function.
Normally you'll use ASSERT_NO_FATAL_FAILURE() when the inner-statement
is a call to a sub-routine.
For consistency, we'll also add an EXPECT_NO_FATAL_FAILURE(statement)
to match.
Original issue reported on code.google.com by [email protected]
on 5 Aug 2008 at 7:24
What steps will reproduce the problem?
1. Create a test which where the expression will throw an exception:
bool ThrowAnException()
{
throw 0;
}
TEST(Test, Exception)
{
EXPECT_TRUE(ThrowAnException());
}
2. Run the test
3. Check the result
What is the expected output? What do you see instead?
Expected output should be something like this:
[ RUN ] Test.Exception
test.cc:113: Failure
Unhandled exception caught in: ThrowAnException()
[ FAILED ] Test.Exception
But the current result is:
[ RUN ] Test.Exception
unknown file: Failure
Exception thrown with code 0xe06d7363 in the test body.
[ FAILED ] Test.Exception
What version of the product are you using? On what operating system?
1.0.1 on Windows
Please provide any additional information below.
The "unknown file: Failure" message is not so handy. At least the source
file and line should be reported.
Original issue reported on code.google.com by [email protected]
on 16 Jul 2008 at 8:01
We need to document the usage of GTEST_HAS_* macros, as they are in the
public API.
Original issue reported on code.google.com by [email protected]
on 18 Sep 2008 at 4:25
On Mac OS X(at least 10.4+) "libtoolize -c" is replaced by "glibtoolize -c".
Original issue reported on code.google.com by [email protected]
on 11 Jul 2008 at 7:14
C++ often requires you to explicitly cast NULL to a specific type when it
is used to invoke a function template, which is tedious. We can add the
following class:
class Null {
public:
template <typename T>
operator T*() const { return NULL; }
};
Then the user should be able to write Null() wherever a NULL pointer is
expected, even when invoking a templatized function.
Original issue reported on code.google.com by [email protected]
on 8 Oct 2008 at 9:35
Reported by Juanjo:
The only problem I found so far is that there are no death tests for
OS X. I know that we do not have clone and that fork by itself is not
thread safe, but my library is also not thread safe and, lacking
exceptions by design, relies on abort()/exit() for signalling errors.
I have come up with a simple solution which consists on activating
death tests but not implementing the ExecDeath... class. Furthermore,
in order to avoid those annoying warnings (couldn't you just print
them once?) about the thread number, I have implemented also
GetThreadCount() for OS X.
The code is very simple and since it may be useful for somebody else,
I have attached it to the end of this message. Please consider
including a variant of it in the next release
Juanjo
Index: include/gtest/internal/gtest-port.h
===================================================================
--- include/gtest/internal/gtest-port.h (revision 83)
+++ include/gtest/internal/gtest-port.h (working copy)
@@ -213,7 +213,7 @@
#endif // GTEST_HAS_STD_STRING
// Determines whether to support death tests.
-#if GTEST_HAS_STD_STRING && defined(GTEST_OS_LINUX)
+#if GTEST_HAS_STD_STRING && (defined(GTEST_OS_LINUX) ||
defined(GTEST_OS_MAC))
#define GTEST_HAS_DEATH_TEST
// On some platforms, <regex.h> needs someone to define size_t, and
// won't compile otherwise. We can #include it here as we already
@@ -464,7 +464,7 @@
// There's no portable way to detect the number of threads, so we
just
// return 0 to indicate that we cannot detect it.
-inline size_t GetThreadCount() { return 0; }
+size_t GetThreadCount();
// Defines tr1::is_pointer (only needed for Symbian).
Index: src/gtest-death-test.cc
===================================================================
--- src/gtest-death-test.cc (revision 83)
+++ src/gtest-death-test.cc (working copy)
@@ -38,6 +38,13 @@
#include <errno.h>
#include <limits.h>
#include <stdarg.h>
+#include <unistd.h>
+extern "C" char **environ;
+#include <sys/types.h>
+#include <sys/mman.h>
+#ifndef MAP_ANONYMOUS
+# define MAP_ANONYMOUS MAP_ANON
+#endif
#endif // GTEST_HAS_DEATH_TEST
#include <gtest/gtest-message.h>
@@ -538,6 +545,8 @@
std::vector<char*> args_;
};
+#ifdef GTEST_OS_LINUX
+
// A struct that encompasses the arguments to the child process of a
// threadsafe-style death test process.
struct ExecDeathTestArgs {
@@ -639,6 +648,8 @@
return OVERSEE_TEST;
}
+#endif // !GTEST_OS_LINUX
+
// Creates a concrete DeathTest-derived class that depends on the
// --gtest_death_test_style flag, and sets the pointer pointed to
// by the "test" argument to its address. If the test should be
@@ -669,7 +680,11 @@
}
if (GTEST_FLAG(death_test_style) == "threadsafe") {
+#ifdef GTEST_OS_LINUX
*test = new ExecDeathTest(statement, regex, file, line);
+#else
+ *test = new NoExecDeathTest(statement, regex);
+#endif
} else if (GTEST_FLAG(death_test_style) == "fast") {
*test = new NoExecDeathTest(statement, regex);
} else {
Index: src/gtest-port.cc
===================================================================
--- src/gtest-port.cc (revision 83)
+++ src/gtest-port.cc (working copy)
@@ -47,6 +47,10 @@
#include <gtest/gtest-message.h>
#include <gtest/internal/gtest-string.h>
+#ifdef GTEST_OS_MAC
+#include <mach/mach_init.h>
+#include <mach/task.h>
+#endif
namespace testing {
namespace internal {
@@ -55,6 +59,20 @@
// Implements RE. Currently only needed for death tests.
+#ifdef GTEST_OS_MAC
+size_t GetThreadCount() {
+ mach_msg_type_number_t thread_count;
+ thread_act_port_array_t thread_list;
+ task_t task = current_task();
+ task_threads(task, &thread_list, &thread_count);
+ return thread_count;
+}
+#else
+size_t GetThreadCount() {
+ return 0;
+}
+#endif // !GTEST_OS_MAC
+
RE::~RE() {
regfree(®ex_);
free(const_cast<char*>(pattern_));
Original issue reported on code.google.com by [email protected]
on 8 Sep 2008 at 11:41
We should create a cheat sheet that can be printed on A4 or letter-sized
paper. To ensure the formatting and allow integration between different
tags/branches, the source file should be in the LaTeX format, from which
PDF can be easily generated.
Original issue reported on code.google.com by [email protected]
on 22 Sep 2008 at 8:35
I tried to do:
class Foo { };
class Bar
{
private:
Foo* m_foo;
public:
Bar() : m_foo(0) { }
Foo* foo(void) { return m_foo; }
}
Bar baz;
EXPECT_EQ(0, baz.foo());
This didn't work until I did this:
EXPECT_EQ((void*)0, baz.foo());
Because we deal with enough pointers in our code, I've implemented
{ASSERT|EXPECT}_NULL and {ASSERT|EXPECT}_NOT_NULL. The attached diff
implements this entirely in <gtest/gtest.h>.
Original issue reported on code.google.com by [email protected]
on 7 Oct 2008 at 6:44
Attachments:
Per Abrahamsen reported that he was able to compile and install Google Test
successfully on Cygwin for MinGW. "make check" fails with some errors
though. The following patch by Per fixes some, but not all, errors.
--- gtest-filepath_test.cc_ORIG 2008-09-18 14:16:58.000000000 +0200
+++ gtest-filepath_test.cc 2008-09-30 21:06:27.575000000 +0200
@@ -61,6 +61,11 @@
#define PATH_SEP "/"
#endif // GTEST_OS_WINDOWS
+#ifdef __MINGW32__
+extern "C" int chdir (const char* dir);
+extern "C" int rmdir (const char* path);
+#endif
+
namespace testing {
namespace internal {
namespace {
--- gtest_unittest.cc_ORIG 2008-09-18 14:16:58.000000000 +0200
+++ gtest_unittest.cc 2008-09-30 21:01:37.864000000 +0200
@@ -1030,6 +1030,8 @@
return;
#elif defined(GTEST_OS_WINDOWS) // If we are on Windows proper.
_putenv((Message() << name << "=" << value).GetString().c_str());
+#elif defined (__MINGW32__)
+ putenv((Message() << name << "=" << value).GetString().c_str());
#else
if (*value == '\0') {
unsetenv(name);
Original issue reported on code.google.com by [email protected]
on 30 Sep 2008 at 10:21
What version of the product are you using? On what operating system?
svn revision 78
SunOS dev01-mel 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Fire-V440
CC: Sun C++ 5.8 Patch 121017-11 2007/05/02
Please provide any additional information below.
The following patch fixes it for me.
Index: test/gtest-filepath_test.cc
===================================================================
--- test/gtest-filepath_test.cc (revision 78)
+++ test/gtest-filepath_test.cc (working copy)
@@ -61,6 +61,11 @@
#define PATH_SEP "/"
#endif // GTEST_OS_WINDOWS
+
+#ifdef GTEST_OS_SUN
+#include <unistd.h>
+#endif // GTEST_OS_SUN
+
namespace testing {
namespace internal {
namespace {
Index: test/gtest_break_on_failure_unittest.py
===================================================================
--- test/gtest_break_on_failure_unittest.py (revision 78)
+++ test/gtest_break_on_failure_unittest.py (working copy)
@@ -81,7 +81,7 @@
# On Unix-like systems, the lowest 8 bits of the exit code is the
# signal number that killed the process (or 0 if it wasn't killed by
# a signal).
- return (exit_code & 255) != 0
+ return (exit_code>>8) == (signal.SIGSEGV + 128)
# The unit test.
Index: include/gtest/internal/gtest-port.h
===================================================================
--- include/gtest/internal/gtest-port.h (revision 78)
+++ include/gtest/internal/gtest-port.h (working copy)
@@ -145,6 +145,11 @@
#define GTEST_OS_MAC
#elif defined __linux__
#define GTEST_OS_LINUX
+#elif defined __sun
+// TODO([email protected]): GTEST_OS_SUN is currently used to mean both "The
+// OS is Solaris" and "The compiler is Sunpro". These meanings should
really be
+// separated in order to better support Solaris compilers other than Sunpro.
+#define GTEST_OS_SUN
#endif // _MSC_VER
// Determines whether ::std::string and ::string are available.
@@ -249,7 +254,7 @@
// struct Foo {
// Foo() { ... }
// } GTEST_ATTRIBUTE_UNUSED;
-#if defined(__GNUC__) && !defined(COMPILER_ICC)
+#if defined(__GNUC__) && !defined(COMPILER_ICC) || defined(GTEST_OS_SUN)
#define GTEST_ATTRIBUTE_UNUSED __attribute__ ((unused))
#else
#define GTEST_ATTRIBUTE_UNUSED
Original issue reported on code.google.com by [email protected]
on 8 Aug 2008 at 11:39
It would be nice to have an Eclipse plug-in for Google Test.
Josha at industrial logic has done some work here.
Original issue reported on code.google.com by [email protected]
on 29 Sep 2008 at 3:17
Google Test should support tests that are parameterized by:
- a set of values,
- a set of implementations of the same interface (in the inheritance
sense), and
- a set of types/values for instantiating some templates.
The above goals may require different constructs.
Original issue reported on code.google.com by [email protected]
on 6 Aug 2008 at 12:48
It should be gtest_main.lib instead of gtest.lib.
Original issue reported on code.google.com by [email protected]
on 15 Jul 2008 at 12:00
The initial release of Google Test contains autotools-based build scripts.
We need to add support for Windows and Mac OS X.
Original issue reported on code.google.com by [email protected]
on 2 Jul 2008 at 7:35
What steps will reproduce the problem?
1. configure and make gtest
2. run make check
What is the expected output? What do you see instead?
I expect the tests to pass. Instead I see the following output
---SNIP---
test/gtest_repeat_test.cc: In member function 'virtual
void<unnamed>::BarDeathTest_ThreadSafeAndFast_Test::TestBody()':
test/gtest_repeat_test.cc:114: error: 'EXPECT_DEATH' was not declared in
this scope
make[1]: *** [test/gtest_repeat_test.o] Error 1
make: *** [check-am] Error 2
---/SNIP---
What version of the product are you using? On what operating system?
gtest-1.0.0
Mac OS X 10.4.11
Please provide any additional information below.
I have attached a patch which causes all tests to pass on this machine. I
tested the patch on my Google corp workstation as well. All tests pass
there, including BarDeathTest.ThreadSafeAndFast.
Original issue reported on code.google.com by [email protected]
on 5 Jul 2008 at 8:41
Attachments:
1. Converted your sln to VS2008
2. Only gtest and gtest_environment_test build without errors
3. All other projects have unresolved externals
gtest 1.0.1. on 64-bit Vista with Visual Studio 2008 Professional
Original issue reported on code.google.com by [email protected]
on 3 Aug 2008 at 7:27
What steps will reproduce the problem?
1. ./configure
2. make
3. make check
What is the expected output? What do you see instead?
When running 'make check', I expect to see a successful build, followed by all
tests passing.
Instead, I see this:
make samples/sample1_unittest samples/sample2_unittest
samples/sample3_unittest
samples/sample4_unittest samples/sample5_unittest samples/sample6_unittest
test/gtest_unittest test/gtest-death-test_test test/gtest-filepath_test
test/gtest-message_test
test/gtest-options_test test/gtest_pred_impl_unittest
test/gtest_environment_test
test/gtest_no_test_unittest test/gtest_main_unittest test/gtest_prod_test
test/gtest_repeat_test
test/gtest_stress_test test/gtest-typed-test_test
make[1]: Entering directory `/home/pberry/gtest/gtest-1.1.0'
depbase=`echo samples/sample1_unittest.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \
if g++ -DHAVE_CONFIG_H -I. -I. -I./config_aux -I. -I./include -g -O2 -MT
samples/sample1_unittest.o -MD -MP -MF "$depbase.Tpo" -c -o
samples/sample1_unittest.o
samples/sample1_unittest.cc; \
then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo"; exit 1; fi
/bin/sh ./libtool --tag=CXX --mode=link g++ -g -O2 -o
samples/sample1_unittest
samples/sample1_unittest.o lib/libgtest_main.la samples/libsamples.la
g++ -g -O2 -o samples/.libs/sample1_unittest samples/sample1_unittest.o
lib/.libs/libgtest_main.so samples/.libs/libsamples.a -Wl,--rpath
-Wl,/usr/local/lib
samples/sample1_unittest.o(.text+0x1303): In function `global constructors
keyed to
_ZN27FactorialTest_Negative_Test10test_info_E':
./include/gtest/internal/gtest-internal.h:484: undefined reference to
`testing::internal::MakeAndRegisterTestInfo(char const*, char const*, char
const*, char const*,
void*, void (*)(), void (*)(), testing::internal::TestFactoryBase*)'
samples/sample1_unittest.o(.text+0x134d):./include/gtest/internal/gtest-internal
.h:484:
undefined reference to `testing::internal::MakeAndRegisterTestInfo(char const*,
char const*,
char const*, char const*, void*, void (*)(), void (*)(),
testing::internal::TestFactoryBase*)'
samples/sample1_unittest.o(.text+0x1397):./include/gtest/internal/gtest-internal
.h:484:
undefined reference to `testing::internal::MakeAndRegisterTestInfo(char const*,
char const*,
char const*, char const*, void*, void (*)(), void (*)(),
testing::internal::TestFactoryBase*)'
samples/sample1_unittest.o(.text+0x13e1):./include/gtest/internal/gtest-internal
.h:484:
undefined reference to `testing::internal::MakeAndRegisterTestInfo(char const*,
char const*,
char const*, char const*, void*, void (*)(), void (*)(),
testing::internal::TestFactoryBase*)'
samples/sample1_unittest.o(.text+0x142b):./include/gtest/internal/gtest-internal
.h:484:
undefined reference to `testing::internal::MakeAndRegisterTestInfo(char const*,
char const*,
char const*, char const*, void*, void (*)(), void (*)(),
testing::internal::TestFactoryBase*)'
samples/sample1_unittest.o(.text+0x1475):./include/gtest/internal/gtest-internal
.h:484: more
undefined references to `testing::internal::MakeAndRegisterTestInfo(char
const*, char const*,
char const*, char const*, void*, void (*)(), void (*)(),
testing::internal::TestFactoryBase*)' follow
collect2: ld returned 1 exit status
make[1]: *** [samples/sample1_unittest] Error 1
make[1]: Leaving directory `/home/pberry/gtest/gtest-1.1.0'
make: *** [check-am] Error 2
What version of the product are you using? On what operating system?
I am using version 1.1.0 on an AMD Opteron 285. The OS is RedHat 4 update 1.
Here is the
result of 'uname -a':
Linux sim12 2.6.9-42.0.10.ELsmp #1 SMP Fri Feb 16 17:13:42 EST 2007 x86_64
x86_64 x86_64
GNU/Linux
And here is the result of gcc --version:
gcc (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.1)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 14 Oct 2008 at 4:09
include/gtest/internal/gtest-type-util.h is generated from
gtest-type-util.h.pump using the 'pump' script, which hasn't been polished
enough to release yet. We should release the script and its documentation.
Original issue reported on code.google.com by [email protected]
on 9 Sep 2008 at 3:04
Some users don't use RTTI in their build. For example, they pass -fno-rtti
to gcc. Google Test's typed tests use RTTI and thus won't compile here.
To make it work for such users, Google Test provides the GTEST_HAS_RTTI
macro for the user to define. However there's no automated test to verify
this. Please add one.
Original issue reported on code.google.com by [email protected]
on 18 Sep 2008 at 4:24
What steps will reproduce the problem?
Follow steps from README files:
$ ${SRCDIR}/configure # Standard GNU configure script, --help for more info
$ make # Standard makefile following GNU conventions
$ make check # Builds and runs all tests - all should pass
What is the expected output? What do you see instead?
Expected output: Builds and runs all tests - all should pass
What I got was:
'make check' fails with following messages:
=====================
FAIL: Tests using the GTEST_BREAK_ON_FAILURE environment variable.
----------------------------------------------------------------------
Traceback (most recent call last):
File "./test/gtest_break_on_failure_unittest.py", line 148, in testEnvVar
expect_seg_fault=1)
File "./test/gtest_break_on_failure_unittest.py", line 131, in RunAndVerify
self.assert_(has_seg_fault == expect_seg_fault, msg)
AssertionError: when GTEST_BREAK_ON_FAILURE=1, an assertion failure in
"/home/toni/work/gtest-1.0.0/test/gtest_break_on_failure_unittest_" should
cause a seg-fault.
======================================================================
FAIL: Tests using the --gtest_break_on_failure flag.
----------------------------------------------------------------------
Traceback (most recent call last):
File "./test/gtest_break_on_failure_unittest.py", line 158, in testFlag
expect_seg_fault=1)
File "./test/gtest_break_on_failure_unittest.py", line 131, in RunAndVerify
self.assert_(has_seg_fault == expect_seg_fault, msg)
AssertionError: when GTEST_BREAK_ON_FAILURE is not set, an assertion
failure in
"/home/toni/work/gtest-1.0.0/test/gtest_break_on_failure_unittest_
--gtest_break_on_failure" should cause a seg-fault.
======================================================================
FAIL: Tests that the flag overrides the environment variable.
----------------------------------------------------------------------
Traceback (most recent call last):
File "./test/gtest_break_on_failure_unittest.py", line 168, in
testFlagOverridesEnvVar
expect_seg_fault=1)
File "./test/gtest_break_on_failure_unittest.py", line 131, in RunAndVerify
self.assert_(has_seg_fault == expect_seg_fault, msg)
AssertionError: when GTEST_BREAK_ON_FAILURE=0, an assertion failure in
"/home/toni/work/gtest-1.0.0/test/gtest_break_on_failure_unittest_
--gtest_break_on_failure" should cause a seg-fault.
----------------------------------------------------------------------
Ran 4 tests in 0.178s
FAILED (failures=3)
FAIL: test/gtest_break_on_failure_unittest.py
...
3 of 26 tests failed
Please report to [email protected]
=====================================================
make[1]: *** [check-TESTS] Error 1
make[1]: Leaving directory `/home/toni/work/gtest-1.0.0'
make: *** [check-am] Error 2
What version of the product are you using? On what operating system?
My environment is Linux: Ubuntu 8.04:
uname -m = i686
uname -r = 2.6.24-16-server
uname -s = Linux
uname -v = #1 SMP Thu Apr 10 13:58:00 UTC 2008
python -V: Python 2.5.2
> gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-mpfr --enable-targets=all --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
Please provide any additional information below.
RunAndVerify function is mention several times but most probably problem is
in this short function from file "gtest_break_on_failure_unittest.py":
def Run(command):
"""Runs a command; returns 1 if it has a segmentation fault, or 0 otherwise.
"""
return os.system(command) == signal.SIGSEGV
Statement:
return os.system(command) == signal.SIGSEGV
never comes "true" because (if you want to test for SIGSEGV):
- signal.SIGSEGV has value 11
- os.system(command) returns 35584 in case that command was killed by
signal SIGSEGV.
Correct check would be (at least in my environment):
ret = os.system(command)
return (ret>>8) == (signal.SIGSEGV + 128)
Why this work is explained in man pages for system() and wait() in Python
and C:
=====================
system( command)
Execute the command (a string) in a subshell. This is implemented by
calling the Standard C function system(), and has the same limitations.
Changes to posix.environ, sys.stdin, etc. are not reflected in the
environment of the executed command.
On Unix, the return value is the exit status of the process encoded in
the format specified for wait(). Note that POSIX does not specify the
meaning of the return value of the C system() function, so the return value
of the Python function is system-dependent.
wait( )
Wait for completion of a child process, and return a tuple containing
its pid and exit status indication: a 16-bit number, whose low byte is the
signal number that killed the process, and whose high byte is the exit
status (if the signal number is zero); the high bit of the low byte is set
if a core file was produced. Availability: Macintosh, Unix.
=====================
Similar result could be get if you start this sequence of command in bash:
=====================
> sleep 30 &
[1] 28937
> pid=$!
> echo $pid
28937
> kill -segv $pid
[1]+ Segmentation fault sleep 30
> wait $pid
> echo $?
139
=====================
Original issue reported on code.google.com by [email protected]
on 9 Jul 2008 at 6:48
What steps will reproduce the problem?
1. Download 1.0.0 release of gtest
2. Unpack to a directory
3. Run ./configure
4. Run make
What is the expected output? What do you see instead?
There should be no errors compiling but I get the following:
depbase=`echo src/gtest.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`; \
if /bin/sh ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H
-I. -I. -I./config_aux -I. -I./include -g -O2 -MT src/gtest.lo -MD -MP
-MF "$depbase.Tpo" -c -o src/gtest.lo src/gtest.cc; \
then mv -f "$depbase.Tpo" "$depbase.Plo"; else rm -f
"$depbase.Tpo"; exit 1; fi
mkdir src/.libs
g++ -DHAVE_CONFIG_H -I. -I. -I./config_aux -I. -I./include -g -O2 -MT
src/gtest.lo -MD -MP -MF src/.deps/gtest.Tpo -c src/gtest.cc -fno-common
-DPIC -o src/.libs/gtest.o
In file included from src/gtest.cc:34:
./include/gtest/gtest.h:74:39: error: gtest-internal.h: No such file or
directory
In file included from ./include/gtest/gtest.h:75,
from src/gtest.cc:34:
./include/gtest/gtest-message.h:57:37: error: gtest-string.h: No such file
or directory
make: *** [src/gtest.lo] Error 1
What version of the product are you using? On what operating system?
gtest: 1.0.0
Mac OS X: 10.5.4
Please provide any additional information below.
The problem is solved if instead of ./configure I use ./configure
CPPFLAGS=-DGTEST_NOT_MAC_FRAMEWORK_MODE. Users should just be able to
./configure && make and have it work out of the box.
Original issue reported on code.google.com by evlogimenos
on 4 Jul 2008 at 11:54
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.