[bug?] non posix version of gtest pulled on linux

[MK8BK]

Describe the bug

I don't know if this is the right place to ask for help, if not please redirect me quickly.

Linux 6.19.14-108.fc42.x86_64,
Intel i7-9750H,
Fedora 42 workstation.

I am brand new to conan.
I have been trying for half a day to setup gtest with conan.
I have this small test project to try and understand what the problem is.
I have three files: CMakeLists.txt, conanfile.txt and gtester.cpp.

# CMakeLists.txt
cmake_minimum_required(VERSION 3.23)
project(conan_gtest CXX)
set(CMAKE_CXX_STANDARD 20)

find_package(GTest REQUIRED)

add_executable(gtester gtester.cpp)

# as specified on the conancenter page for gtest 1.17.0
target_link_libraries(gtester PRIVATE gtest::gtest)

[requires]
gtest/1.17.0

[generators]
CMakeDeps
CMakeToolchain

[layout]
cmake_layout

#include <gtest/gtest.h>

// Demonstrate some basic assertions.
TEST(HelloTest, BasicAssertions) {
  // Expect two strings not to be equal.
  EXPECT_STRNE("hello", "world");
  // Expect equality.
  EXPECT_EQ(7 * 6, 42);
}

~/conan_gtest$ conan profile detect

detect_api: Found cc=gcc-15.2.1
detect_api: gcc>=5, using the major as version
detect_api: gcc C++ standard library: libstdc++11

Detected profile:
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=15
os=Linux

WARN: This profile is a guess of your environment, please check it.
WARN: The output of this command is not guaranteed to be stable and can change in future Conan versions.
WARN: Use your own profile files for stability.
Saving detected profile to ~/.conan2/profiles/default

# to build from source, you need cmake>=3.23 and conan
~/conan_gtest$ conan install . --output-folder=build --build=missing
[...]
conanfile.txt: Generating aggregated env files
conanfile.txt: Generated aggregated env files: ['conanbuild.sh', 'conanrun.sh']
Install finished successfully

~/conan_gtest$ cmake --preset conan-release
[...]
-- Build files have been written to: ~/conan_gtest/build/build/Release

~/conan_gtest$ cmake --build --preset conan-release
[ 50%] Building CXX object CMakeFiles/gtester.dir/gtester.cpp.o
[100%] Linking CXX executable gtester
/usr/bin/ld: ~/.conan2/p/b/gtest50e39ca0414fc/p/lib/libgtest.a(gtest-all.cc.o): in function `testing::internal::RE::~RE()':
gtest-all.cc:(.text+0x410d): undefined reference to `regfreeA'
/usr/bin/ld: gtest-all.cc:(.text+0x4116): undefined reference to `regfreeA'
/usr/bin/ld: ~/.conan2/p/b/gtest50e39ca0414fc/p/lib/libgtest.a(gtest-all.cc.o): in function `testing::internal::RE::FullMatch(char const*, testing::internal::RE const&)':
gtest-all.cc:(.text+0x415a): undefined reference to `regexecA'
/usr/bin/ld: ~/.conan2/p/b/gtest50e39ca0414fc/p/lib/libgtest.a(gtest-all.cc.o): in function `testing::internal::RE::PartialMatch(char const*, testing::internal::RE const&)':
gtest-all.cc:(.text+0x419a): undefined reference to `regexecA'
/usr/bin/ld: ~/.conan2/p/b/gtest50e39ca0414fc/p/lib/libgtest.a(gtest-all.cc.o): in function `testing::internal::RE::Init(char const*)':
gtest-all.cc:(.text+0x255e7): undefined reference to `regcompA'
/usr/bin/ld: gtest-all.cc:(.text+0x2560b): undefined reference to `regcompA'
collect2: error: ld returned 1 exit status
gmake[2]: *** [CMakeFiles/gtester.dir/build.make:105: gtester] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:87: CMakeFiles/gtester.dir/all] Error 2
gmake: *** [Makefile:91: all] Error 2

Even with AI, I could not find the root cause of the problem. I tried to delete the .conan2 folder
and retry the same commands, changed the gtest version to 1.16.0 (oldest supported version).
It seems as though a non posix version of gtest is installed each time, judging by the
presence of regcompA instead of regcomp for posix systems.

WHAT DO????

How to reproduce it

No response

[memsharded]

Hi @MK8BK

Thanks for your feedback.

I think the important part might be here:

Fedora 42 workstation.

This is maybe a binary incompatibility. ConanCenter binaries are built with a relatively old libc, etc, to try to provide a wide binary compatibility across different Linux distros. But this is not perfect, and some distros, either older or very bleeding edge might have some issues in some cases.

Could you please try to force the build from sources of the packages locally, instead of downloading the pre-compiled binaries from ConanCenter:

conan install . --output-folder=build --build="*"

(I am interested in the output of your previous command in --build=missing, I am guessing that it downloaded binaries).

Try cleaning your CMake cache, the Conan cache (conan remove "*" -c), doing that conan install, then the cmake build and let us know.

[MK8BK]

Hi, thanks for the speedy reply, i cleaned my cache (deleted the whole build folder). I tried the standard way to use gtest in a cmake project without conan, i got the same error so i think this might be a gtest problem, if so feel free to close this issue. I opened this issue with gtest. Nevertheless I did try the cleaning step and building everything locally, new errors popped up including the notable discovery that my /usr/bin/c++ compiler (which is gcc 15~) is not able to compile a simple test program.

11121 

-- Check for working CXX compiler: /usr/bin/c++
    1 -- Check for working CXX compiler: /usr/bin/c++ - broken
    2 CMake Error at /usr/share/cmake/Modules/CMakeTestCXXCompiler.cmake:73 (message):
    3   The C++ compiler
    4   
    5     "/usr/bin/c++"
    6 
    7   is not able to compile a simple test program.
    8   
    9   It fails with the following output:
   10   
   11     Change Dir: '/home/mk8bk/.conan2/p/b/ninjacfd96f4cefccb/b/build/Release/CMakeFiles/CMakeScratch/TryCompile-DaPGJl'
   12     
   13     Run Build Command(s): /usr/bin/cmake -E env VERBOSE=1 /usr/bin/gmake -f Makefile cmTC_65fd9/fast

I linked the full output (11k lines omg).

bruh.txt

[memsharded]

Yes, this is a bit unexpected, I see the error is happening while building the ninja package (this is a tool-require to build some other dependencies. It might be workarounded by using for example [platform_tool_requires] to tell you have it in the system, and do not need it as a Conan package, but this would be a workaround, in theory the package should build cleanly).

The error:

/usr/bin/ld: cannot find -lstdc++: No such file or directory
/usr/bin/ld: have you installed the static version of the stdc++ library ?

Seems to indicate that the build of ninja requires static C++ stdlib, which doesn't happen to be installed for your compiler, while in the general case it is most likely installed with the compiler. Have you tried to install it and relaunch? (YOu can try with the --build=missing now to avoid rebuilding everything again, or do a shortcut like conan install --tool-requires=ninja/version --build=ninja/version

[memsharded]

Hi @MK8BK

Did the above help? Did you try to install the static libcxx support for your compiler?
Any further question or comment? Thanks for the feedback.

[MK8BK]

Sorry for the delay, was working on something else.
Ok i did install the libstdc++-static and reexecuted the same commands.

sudo dnf install libstdc++-static

The "not able to compile a simple test program" vanished.
The gtest regcompA error remains. I added the whole output for each command this time.
I will try and make things work with cmake and gtest alone. If the problem is fixed in that setting,
it might be that some system configuration of mine is messed up and the conan+cmake+gtest project will start working
just fine after i fix it; in which case I will close this issue and specify the system configuration problem. If somehow
the error is solved for cmake+gtest but remains for cmake+gtest+conan, i'll come back here and notify you.

output of conan install . --output-folder=build --build=missing
r1.txt

output of conan remove "*" -c
r2.txt

output of conan install . --output-folder=build --build="*"
r3.txt

output of cmake --preset conan-release
r4.txt

output of cmake --build --preset conan-release
r5.txt

Thanks again for the very speedy replies

[memsharded]

It seems the AI might give some interesting pointers for this, aligned with previous observations, like:

This specific error—where the linker looks for regcompA, regexecA, and regfreeA instead of the standard POSIX regcomp, regexec, and regfree on a Linux system—is almost always caused by a header collision or an environment pollution issue, compounded by mixing bleeding-edge toolchains (Fedora 42 + GCC 15) with pre-compiled packages.

Here are the primary sources of this issue and how to resolve them:

1. The "Boost Header Pollution" Trap (Most Likely)
   The symbols regcompA, regexecA, and regfreeA are not standard Linux/glibc functions. They are internal aliases used by the Boost.Regex POSIX compatibility wrapper.