Gmock issue

John Ralls jralls at ceridwen.us
Sat Jan 13 18:59:11 EST 2018



> On Jan 13, 2018, at 11:21 AM, P Levine <plevine457 at gmail.com> wrote:
> 
> On Saturday, January 13, 2018 5:33:12 AM CET John Ralls wrote:
> 
>> 
>> That doesn’t answer or even address the questions.
>> 
>> You seem to have missed that many projects, GnuCash included, set numerous
>> CPPFlags and LDFLAGS in their configuration scripts... and that’s a
>> completely separate issue from whatever restrictions Gentoo attempts to
>> impose on its users.
> 
> Yes.  The reason given by Googletest for suggesting against
> pre-compiled libraries is that dependent projects might be built with
> different flags causing different definitions for the same symbol.
> Consistent, safe optimization and arch flags can't do that John.  And
> that's our bread and butter.

No. Different arch flags will result in the library not linking. Different optimization flags will change the generated machine code but shouldn't (absent bugs in the compiler) affect either side effects or return value. 

Read what the Googletest folks actually said: "If you compile Google Test 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 Google Test)."

Due to the use of #if. That means it has to be a flag visible to the preprocessor. Optimization flags don't qualify. Architecture flags do, but differing architecture flags lead to a straightforward link error with a clear message. That's not going to affect anyone's sanity. For example: #if GTEST_HAS_EXCEPTIONS would normally be true but would be false if the project-under-test sets -fno-exceptions. That's squarely in the category of compiler flag likely to be set in a project build system.

> 
>> No, I don’t believe that using static libraries will mask ODR violations and
>> bringing up a Googletest bug is utterly irrelevant.
> 
> You don't have to believe it John.  I'ts a well documented and
> reproducible fact.  The doublefree error shows up because the string
> vector's destructor's symbol exists more than once because of a build
> time linking error.  It doesn't show up when built as a static
> library.

That's not a code problem that's being masked by using a static library, it's a build-system error that's being avoided by linking a static library and thus taking a different path through the build system. The PR changes the build system, not the code.

> 
> 
>> Geert has already told you that we’ll accept reasonable patches, though you
>> should recognize that if someone at Gentoo isn’t keyed in to maintaining
>> them they’ll bitrot.
> 
> I would expect nothing less.

I hope you mean that you expect nothing more, because if you do expect more you'll be disappointed.

> 
>> There’s another problem here: You say that you’ve already applied Googletest
>> PR 1339 in Gentoo. Googletest hasn’t accepted that PR, so you’ve forked
>> Googletest. Is that clearly documented to your users? Do you have written
>> permission from Google to continue to call your fork Googletest? See the
>> third bullet in https://github.com/google/googletest/blob/master/LICENSE
>> <https://github.com/google/googletest/blob/master/LICENSE>.
>> 
>> How many other project’s licenses does Gentoo violate?
> 
> I'm sure on some level you realize how absurd that statement is.
> Patched code doesn't fit the definition of "derived" by any stretch of
> the imagination.

Patched code is *exactly* the definition of a derivative work. The only possible question is how big a patch is necessary to trigger the license provision, and the only conclusive way that gets decided is in court. I try to avoid court, it's expensive. YMMV, of course.

A better answer would be "Have another look at the PR: It changes only CMakeLists.txt and has no effect on the actual library, so it's not really a material change."

Regards,
John Ralls




More information about the gnucash-devel mailing list