Bug#994419: libgtest-dev: missing dependency on libgmock-dev

[Timo Röhling]

Package: libgtest-dev
Version: 1.10.0.20201025-1.1
Severity: important
Tag: patch

Dear maintainer,

the GTestTargets.cmake that is shipped in libgtest-dev also exports
the GTest::gmock and GTest::gmock_main targets. However, the
corresponding libraries libgmock.a and libgmock_main.a are shipped
in libgmock-dev. This causes a fatal error and prevents successful
CMake configuration in dependent projects.

Please add Depends: libgmock-dev to libgtest-dev.


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯

[Timo Röhling]

Control: severity 994419 serious
Control: affects 994419 + src:fastcdr
Control: tags 994419 + ftbfs

Hi,

On Wed, 15 Sep 2021 21:25:49 +0200 Timo =?utf-8?Q?R=C3=B6hling?= <roeh...@debian.org> wrote:
> the GTestTargets.cmake that is shipped in libgtest-dev also exports
> the GTest::gmock and GTest::gmock_main targets. However, the
> corresponding libraries libgmock.a and libgmock_main.a are shipped
> in libgmock-dev. This causes a fatal error and prevents successful
> CMake configuration in dependent projects.
>
> Please add Depends: libgmock-dev to libgtest-dev.

I just noticed that this bug not only breaks autopkgtest but also
causes fastcdr to FTBFS.

In case you're wondering, apparently this bug has been exposed by
the changes in the new CMake version that has hit unstable, so this
will possibly affect more packages.

[Steven Robbins]

On Wednesday, September 15, 2021 2:48:01 P.M. CDT Timo Röhling wrote:

> > Please add Depends: libgmock-dev to libgtest-dev.
>
> I just noticed that this bug not only breaks autopkgtest but also
> causes fastcdr to FTBFS.
>
> In case you're wondering, apparently this bug has been exposed by
> the changes in the new CMake version that has hit unstable, so this
> will possibly affect more packages.

Intriguing. Note that gtest is intended as the base layer (gmock is built on
top of gtest), so it would be a loss to have libgtest-dev pull in gmock.
Hopefully there's an alternative fix.

-Steve

[Steven Robbins]

On Wednesday, September 15, 2021 2:25:49 P.M. CDT Timo Röhling wrote:
> Package: libgtest-dev
> Version: 1.10.0.20201025-1.1

I've discovered that upstream has released 1.11 -- which I'll package up.

> the GTestTargets.cmake that is shipped in libgtest-dev also exports
> the GTest::gmock and GTest::gmock_main targets. However, the
> corresponding libraries libgmock.a and libgmock_main.a are shipped
> in libgmock-dev. This causes a fatal error and prevents successful
> CMake configuration in dependent projects.

Do you have a minimal reproduction by any chance? I'd like to test out 1.11
-- just in case it fixes the problem.

Thanks,
-Steve

[Steven Robbins]

On Wednesday, September 15, 2021 2:48:01 P.M. CDT Timo Röhling wrote:

> Control: tags 994419 + ftbfs

I thought this tag was for the case that the package fails to build from
source. ?? https://www.debian.org/Bugs/Developer

> I just noticed that this bug not only breaks autopkgtest

What autopkgtest? I don't think googletest has one.

> but also causes fastcdr to FTBFS.

I can't reproduce this. I used "apt source fastcdr" to get the 1.0.21-2
sources and they built fine.

Can you provide explicit instructions on reproducing the issue, please?

Best,
-Steve

[Timo Röhling]

* Steven Robbins <st...@sumost.ca> [2021-09-15 18:17]:

>> In case you're wondering, apparently this bug has been exposed by
>> the changes in the new CMake version that has hit unstable, so this
>> will possibly affect more packages.
>Intriguing. Note that gtest is intended as the base layer (gmock is built on
>top of gtest), so it would be a loss to have libgtest-dev pull in gmock.
>Hopefully there's an alternative fix.

AFAICT the root cause is that upstream exports both GTest and GMock
targets to the same export set (GTestTargets), which causes problems
if only one of those is installed.

One alternative solution would be to patch the upstream CMake files
and export GMock independently with their own GMockConfig.cmake and
GMockTargets.cmake. Then, for backwards compatibility, you could
add something like

find_package(GMock QUIET)
if(NOT GMock_FOUND)
message(STATUS "GMock not found, targets will not be imported")
endif()

to the end of GTestConfig.cmake.

[Steven Robbins]

On Thursday, September 16, 2021 1:07:19 A.M. CDT you wrote:
> * Steven Robbins <st...@sumost.ca> [2021-09-15 20:52]:

> >I thought this tag was for the case that the package fails to build from
> >source. ?? https://www.debian.org/Bugs/Developer
>

> I thought this is also transitively for FTBFS caused in other
> packages, but I might be wrong on this. Feel free to adjust the tags
> if you think it is mislabeled.

Well, Adrian Bunk chimed in saying it is used "in practice" transitively. But
that's the first I've heard of it and contrary to what the cited doc says. So
I prefer to remove the tag.

> >> I just noticed that this bug not only breaks autopkgtest
> >
> >What autopkgtest? I don't think googletest has one.
>

> Sorry for the confussion, that also refers to fastcdr, which has a
> failing autopkgtest here:
> https://ci.debian.net/data/autopkgtest/testing/amd64/f/fastcdr/15272003/log.
> gz

> >I can't reproduce this. I used "apt source fastcdr" to get the 1.0.21-2
> >sources and they built fine.
>

> Did you use the latest CMake version from unstable, i.e. CMake
> 3.21.2? I'll attach a build log from my pbuilder sid chroot. The
> relevant failure occurs at line 698.

Thanks for this. It turns out that my mirror still has cmake at 3.18.4-2.
Also I realise now I was testing on a system that had both libgtest-dev and
libgmock-dev installed -- so I wouldn't have triggered it anyway. Will test
properly tonight.

Best,
-Steve

[Timo Röhling]

Forgot the URL. Sorry for all the noise. I promise to stop sending
further emails now ;)
https://github.com/google/googletest/pull/3376

[Timo Röhling]

* Steven Robbins <st...@sumost.ca> [2021-09-16 07:58]:
>So it looks like gtest 1.11.0 may well have fixed it. There's a passing test
>now: https://ci.debian.net/data/autopkgtest/testing/amd64/f/fastcdr/15289175/
>log.gz
Unfortunately, that is a false negative because autopkgtest uses
testing versions for dependencies by default. It's building with
CMake 3.18.4, which does not trigger the bug.

[Steven Robbins]

On Thursday, September 16, 2021 1:07:19 A.M. CDT you wrote:

> Sorry for the confussion, that also refers to fastcdr, which has a
> failing autopkgtest here:
> https://ci.debian.net/data/autopkgtest/testing/amd64/f/fastcdr/15272003/log.
> gz

So it looks like gtest 1.11.0 may well have fixed it. There's a passing test
now: https://ci.debian.net/data/autopkgtest/testing/amd64/f/fastcdr/15289175/
log.gz

-Steve

[Timo Röhling]

Hi Steven,

On Thu, 16 Sep 2021 08:15:31 +0200 Timo Röhling <roeh...@debian.org> wrote:
> One alternative solution would be to patch the upstream CMake files
> and export GMock independently with their own GMockConfig.cmake and
> GMockTargets.cmake. Then, for backwards compatibility, you could
> add something like
>
> find_package(GMock QUIET)
> if(NOT GMock_FOUND)
> message(STATUS "GMock not found, targets will not be imported")
> endif()
>
> to the end of GTestConfig.cmake.

I have simplified and and improved this approach further and come up
with a working solution. I opened an MR in Salsa, which is probably
most convenient, but I'll attach the diff here for reference.