'make install' considered harmful

159 views
Skip to first unread message

Zhanyong Wan (λx.x x)

unread,
Jan 17, 2010, 2:15:59 AM1/17/10
to Google C++ Testing Framework, Google C++ Mocking Framework
Hi, users of gtest and gmock,

In the README file for gtest and gmock, we said that you could install
compiled gtest and gmock libraries on *nix systems using 'make
install'. Then every user of your machine can write tests without
recompiling gtest or gmock.

This seemed like a good idea when we wrote the README, but it has a
got-cha: every user needs to compile his tests using the same compiler
flags used to compile the installed gtest/gmock libraries; otherwise
he may run into undefined behaviors (i.e. the tests can behave
strangely and may even crash for no obvious reasons).

Why? Because C++ has this thing called the One-Definition Rule: if
two C++ source files contain different definitions of the same
class/function/variable, and you link them together, you violate the
rule. The linker may or may not catch the error (in many cases it's
not required by the C++ standard to catch the violation). If it
doesn't, you get strange run-time behaviors that are unexpected and
hard to debug.

If you compile gtest and your test code using different compiler
flags, they may see different definitions of the same
class/function/variable (e.g. due to the use of #if in the code).
Therefore, for your sanity, we recommend to avoid using the installed
gtest/gmock libraries. Instead, each project should compile
gtest/gmock itself such that it can be sure that the same flags are
used for both gtest/gmock and the tests.

For this reason, we now consider it a bad practice to run 'make
install'. We'll remove the instructions from README soon. Thanks,

--
Zhanyong

Zhanyong Wan (λx.x x)

unread,
Mar 25, 2010, 3:34:25 PM3/25/10
to Dmytro Ovdiienko, Google C++ Testing Framework, Google C++ Mocking Framework
(adding the mailing lists back)

Hi Dmytro,

2010/3/25 Dmytro Ovdiienko <dmitriy....@gmail.com>:
> Hi Zhanyong,
>
> According to this logic we should not use installed boost, xerces,
> openssl etc. It is not useful.

Boost is mostly a header-only library, so the logic doesn't apply there.

Not sure about xerces and openssl.

> IMHO it is better to create some guards/fences and not allow user to
> link application or create option-neutral interface.

--
Zhanyong

Zhanyong Wan (λx.x x)

unread,
Mar 26, 2010, 11:32:29 AM3/26/10
to Josh Kelley, Google C++ Testing Framework, Google C++ Mocking Framework
2010/3/26 Josh Kelley <jos...@gmail.com>:
> 2010/3/25 Zhanyong Wan (λx.x x) <w...@google.com>

>>
>> (adding the mailing lists back)
>>
>> Hi Dmytro,
>>
>> 2010/3/25 Dmytro Ovdiienko <dmitriy....@gmail.com>:
>> > Hi Zhanyong,
>> >
>> > According to this logic we should not use installed boost, xerces,
>> > openssl etc. It is not useful.
>>
>> Boost is mostly a header-only library, so the logic doesn't apply there.
>>
>> Not sure about xerces and openssl.
>
> Out of curiosity, could you give any examples of flags or compiler options
> that would result in violating the ODR?

gtest has many classes/functions whose definitions are controlled by
#if. If you pass different -DGTEST_HAS_FOO=1 flags to different
translation units, you'll violate the ODR. Or sometimes people use -D
to select which malloc library to use (debug vs release), and you have
to use the same malloc library across the board.

--
Zhanyong

Reply all
Reply to author
Forward
0 new messages