We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

Coverage remained the same at 92.041% when pulling 5402672 on ambitslix:master into e5ea03c on google:master.

So.
I've digged, and it is possible in principle:

diff --git a/cmake/benchmark.pc.in b/cmake/benchmark.pc.in
index 43ca8f9..f465931 100644
--- a/cmake/benchmark.pc.in
+++ b/cmake/benchmark.pc.in
@@ -7,6 +7,6 @@ Name: @PROJECT_NAME@
 Description: Google microbenchmark framework
 Version: @VERSION@
 
-Libs: -L${libdir} -lbenchmark
+Libs: -L${libdir} -l$<TARGET_FILE_BASE_NAME:benchmark>
 Libs.private: -lpthread
 Cflags: -I${includedir}
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 81c902c..008e566 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -84,7 +84,7 @@ write_basic_package_version_file(
 )
 
 configure_file("${PROJECT_SOURCE_DIR}/cmake/Config.cmake.in" "${project_config}" @ONLY)
-configure_file("${PROJECT_SOURCE_DIR}/cmake/benchmark.pc.in" "${pkg_config}" @ONLY)
+file(GENERATE OUTPUT "${pkg_config}" INPUT "${PROJECT_SOURCE_DIR}/cmake/benchmark.pc.in")
 
 if (BENCHMARK_ENABLE_INSTALL)
   # Install target (will install the library to specified CMAKE_INSTALL_PREFIX variable)

The caveat being, TARGET_FILE_BASE_NAME only appeared in CMake-3.15.

I think we should revert #923 instead.

Ok I've digged a bit more too, and I realized that I've been spending too much time on something that should be rather simple, and it usually means I'm doing something the wrong way...so I've come to the conclusion that I will avoid using pkg-config if possible for a few reasons:

1. Cmake has it's own facility to handle what pkg-config does, and after all this is cmake
2. There are only awkward solutions to this issue using pkg-config via cmake
3. Projects using cmake neglect pkg-config support, because of the above

Perhaps it's best to not have pkg-config support at all rather then broken support.

I switched all my 3rd party projects to cmake only, If I find I need a package that only has pkg-config support that it shall have proper pkg-config support hopefully. And if not than I won't try fixing that via cmake, I will just do what I've always done; rename files manually.

The caveat being, TARGET_FILE_BASE_NAME only appeared in CMake-3.15.

And even thought TARGET_FILE_NAME is already present in cmake-3.5,
TARGET_FILE_SUFFIX/TARGET_FILE_PREFIX were also only added in 3.15,
so i'm not sure how we could workaround this..

I would remove pkg-config (pc) support as it is broken, there are no good fixes. Or at least note in the documentation, to not use it in the future. It's a tool on top of another tool that does the same thing with different syntax at this point.