StoneThrow's questions

我处于交叉编译环境中，我的项目需要针对 Linux、Windows 和自定义目标进行编译，而自定义目标在 Windows 上进行交叉编译。

该项目使用 googletest 进行单元测试，并在 CMake 查找文件中包含以下内容：

# FindGTest.cmake
if (CMAKE_SYSTEM_NAME STREQUAL "TheTarget")
  FetchContent_Declare(
      GTest
      GIT_REPOSITORY https://github.com/google/googletest.git
      GIT_TAG v1.14.0)
  FetchContent_MakeAvailable(GTest)
else()
    find_package(GTest CONFIG REQUIRED)
endif()

Windows 和 Linux 版本未进行交叉编译，并且编译良好。但对于自定义目标，我收到以下编译错误（为便于阅读进行了编辑）：

C:/dev/project/build/_deps/gtest-src/googletest/include\gtest/internal/gtest-port.h:2058:38: error: use of undeclared identifier 'isatty'
...
C:/dev/project/build/_deps/gtest-src/googletest/include\gtest/internal/gtest-port.h:2087:44: error: use of undeclared identifier 'chdir'
...
C:/dev/project/build/_deps/gtest-src/googletest/include\gtest/internal/gtest-port.h:2135:10: error: use of undeclared identifier 'getenv'; did you mean 'GetEnv'?
...
C:/dev/project/_deps/gtest-src/googletest\src/gtest-death-test.cc:1106:27: error: use of undeclared identifier 'pipe'
...
C:/dev/project/build/_deps/gtest-src/googletest\src/gtest-death-test.cc:1119:27: error: use of undeclared identifier 'fork'
...
C:/dev/project/build/_deps/gtest-src/googletest\src/gtest-death-test.cc:1204:3: error: use of undeclared identifier 'execv'
...
C:/dev/project/build/_deps/gtest-src/googletest\src/gtest-filepath.cc:115:18: error: use of undeclared identifier 'getcwd'

如何解决交叉编译目标的这些编译错误？
有没有办法通过为构建提供正确的宏组合（例如使用 CMakeadd_definition()语句）来实现这一点？
或者我必须创建 gtest 的自定义版本？也就是说，我想这意味着我不应该使用FetchContent_Declare()/FetchContent_MakeAvailable()或find_package()包含 googletest，而是应该将 googletest 作为我的项目的子目录，可能需要更改代码来解决未定义函数的使用问题（？）

以下 CMakePresets.json 演示了如何强制使用 configurePresets 条件设置环境变量：

{
  "version": 3,
  "cmakeMinimumRequired": {
    "major": 3,
    "minor": 20
  },
  "configurePresets": [
    {
      "name": "fail_if_no_foo",
      "displayName": "Fail if no FOO",
      "description": "Demo failing if environment variable FOO is unset",
      "binaryDir": "${sourceDir}/build",
      "generator": "Unix Makefiles",
      "condition": {
        "type": "notEquals",
        "lhs": "$penv{FOO}",
        "rhs": ""
      }
    }
  ]
}

$ cmake --preset fail_if_no_foo
CMake Error: Could not use disabled preset "fail_if_no_foo"
$ FOO=bar cmake --preset fail_if_no_foo
-- Configuring done
-- Generating done
-- Build files have been written to: /home/user/dev/cmake_learn/preset_condition/build
$

下面的修改表明条件可以被继承：

{
  "version": 3,
  "cmakeMinimumRequired": {
    "major": 3,
    "minor": 20
  },
  "configurePresets": [
    {
      "name": "fail_if_no_foo",
      "displayName": "Fail if no FOO",
      "description": "Demo failing if environment variable FOO is unset",
      "binaryDir": "${sourceDir}/build",
      "generator": "Unix Makefiles",
      "condition": {
        "type": "notEquals",
        "lhs": "$penv{FOO}",
        "rhs": ""
      }
    },
    {
      "name": "inherited_preset",
      "inherits": "fail_if_no_foo",
      "displayName": "Inherited fail if no FOO",
      "description": "Demo inherited condition to fail if environment variable FOO is unset"
    }
  ]
}

$ cmake --preset inherited_preset
CMake Error: Could not use disabled preset "inherited_preset"
$ FOO=bar cmake --preset inherited_preset
-- Configuring done
-- Generating done
-- Build files have been written to: /home/user/dev/cmake_learn/preset_condition/build
$

但是，如果继承的 conditionPresets 引入了自己的条件，则父条件的继承似乎就会消失：

{
  "version": 3,
  "cmakeMinimumRequired": {
    "major": 3,
    "minor": 20
  },
  "configurePresets": [
    {
      "name": "fail_if_no_foo",
      "displayName": "Fail if no FOO",
      "description": "Demo failing if environment variable FOO is unset",
      "binaryDir": "${sourceDir}/build",
      "generator": "Unix Makefiles",
      "condition": {
        "type": "notEquals",
        "lhs": "$penv{FOO}",
        "rhs": ""
      }
    },
    {
      "name": "inherited_preset",
      "inherits": "fail_if_no_foo",
      "displayName": "Inherited fail if no FOO",
      "description": "Demo inherited condition to fail if environment variable FOO is unset",
      "condition": {
        "type": "equals",
        "lhs": "${hostSystemName}",
        "rhs": "Linux"
      }
    }
  ]
}

$ uname -s
Linux
$ cmake --preset inherited_preset
-- Configuring done
-- Generating done
-- Build files have been written to: /home/user/dev/cmake_learn/preset_condition/build
$

有没有办法在当前configurePreset中实现的条件与继承的configurePreset中的条件之间实现“与”关系？
我想强制执行“Linux”并且父环境定义的inherited_preset条件。 CMake Presets 文档注释了一个关键字，但没有给出如何使用它的示例，而且我还没有弄清楚如何使用它来实现我的需求。${hostSystemName}FOO
allOf

以下是我从文档中解释如何使用的两次尝试allOf：

{
  "version": 3,
  "cmakeMinimumRequired": {
    "major": 3,
    "minor": 20
  },
  "configurePresets": [
    {
      "name": "fail_if_no_foo",
      "displayName": "Fail if no FOO",
      "description": "Demo failing if environment variable FOO is unset",
      "binaryDir": "${sourceDir}/build",
      "generator": "Unix Makefiles",
      "condition": {
        "allOf": {
          "conditions": [
            {
              "type": "notEquals",
              "lhs": "$penv{FOO}",
              "rhs": ""
            }
          ]
        }
      }
    },
    {
      "name": "inherited_preset",
      "inherits": "fail_if_no_foo",
      "displayName": "Inherited fail if no FOO",
      "description": "Demo inherited condition to fail if environment variable FOO is unset",
      "condition": {
        "type": "equals",
        "lhs": "${hostSystemName}",
        "rhs": "Linux"
      }
    }
  ]
}

{
  "version": 3,
  "cmakeMinimumRequired": {
    "major": 3,
    "minor": 20
  },
  "configurePresets": [
    {
      "name": "fail_if_no_foo",
      "displayName": "Fail if no FOO",
      "description": "Demo failing if environment variable FOO is unset",
      "binaryDir": "${sourceDir}/build",
      "generator": "Unix Makefiles",
      "condition": {
        "allOf": {
          "conditions": [
            {
              "type": "notEquals",
              "lhs": "$penv{FOO}",
              "rhs": ""
            }
          ]
        }
      }
    },
    {
      "name": "inherited_preset",
      "inherits": "fail_if_no_foo",
      "displayName": "Inherited fail if no FOO",
      "description": "Demo inherited condition to fail if environment variable FOO is unset",
      "condition": {
        "allOf": {
          "conditions": [
            {
              "type": "equals",
              "lhs": "${hostSystemName}",
              "rhs": "Linux"
            }
          ]
        }
      }
    }
  ]
}

...但是两次尝试都因相同的错误而解析失败：

$ cmake --preset fail_if_no_foo
CMake Error: Could not read presets from /home/user/dev/cmake_learn/preset_condition: Invalid preset condition

更新：我认为我在之前尝试使用allOf. 以下尝试进行解析，但仍然无法实现强制执行子级和父级条件的所需行为：

{
  "version": 3,
  "cmakeMinimumRequired": {
    "major": 3,
    "minor": 20
  },
  "configurePresets": [
    {
      "name": "fail_if_no_foo",
      "displayName": "Fail if no FOO",
      "description": "Demo failing if environment variable FOO is unset",
      "binaryDir": "${sourceDir}/build",
      "generator": "Unix Makefiles",
      "condition": {
        "type": "allOf",
        "conditions": [
          {
            "type": "notEquals",
            "lhs": "$penv{FOO}",
            "rhs": ""
          }
        ]
      }
    },
    {
      "name": "inherited_preset",
      "inherits": "fail_if_no_foo",
      "displayName": "Inherited fail if no FOO",
      "description": "Demo inherited condition to fail if environment variable FOO is unset",
      "condition": {
        "type": "allOf",
        "conditions": [
          {
            "type": "equals",
            "lhs": "${hostSystemName}",
            "rhs": "Linux"
          }
        ]
      }
    }
  ]
}

$ cmake --preset fail_if_no_foo
CMake Error: Could not use disabled preset "fail_if_no_foo"
$ FOO=bar cmake --preset fail_if_no_foo
-- Configuring done
-- Generating done
-- Build files have been written to: /home/user/dev/cmake_learn/preset_condition/build
$ cmake --preset inherited_preset
-- Configuring done
-- Generating done
-- Build files have been written to: /home/user/dev/cmake_learn/preset_condition/build
$

当我在 CMake 项目中单击“管理配置...”时，Visual Studio 为我生成了以下 CMakePresets.json：

{
  "version": 3,
  "configurePresets": [
    {
      "name": "windows-base",
      "description": "Target Windows with the Visual Studio development environment.",
      "hidden": true,
      "generator": "Ninja",
      "binaryDir": "${sourceDir}/out/build/${presetName}",
      "installDir": "${sourceDir}/out/install/${presetName}",
      "cacheVariables": {
        "CMAKE_C_COMPILER": "cl.exe",
        "CMAKE_CXX_COMPILER": "cl.exe"
      },
      "condition": {
        "type": "equals",
        "lhs": "${hostSystemName}",
        "rhs": "Windows"
      }
    },
    {
      "name": "x64-debug",
      "displayName": "x64 Debug",
      "description": "Target Windows (64-bit) with the Visual Studio development environment. (Debug)",
      "inherits": "windows-base",
      "architecture": {
        "value": "x64",
        "strategy": "external"
      },
      "cacheVariables": { "CMAKE_BUILD_TYPE": "Debug" }
    },
    {
      "name": "x64-release",
      "displayName": "x64 Release",
      "description": "Target Windows (64-bit) with the Visual Studio development environment. (RelWithDebInfo)",
      "inherits": "x64-debug",
      "cacheVariables": { "CMAKE_BUILD_TYPE": "Release" }
    },
    {
      "name": "x86-debug",
      "displayName": "x86 Debug",
      "description": "Target Windows (32-bit) with the Visual Studio development environment. (Debug)",
      "inherits": "windows-base",
      "architecture": {
        "value": "x86",
        "strategy": "external"
      },
      "cacheVariables": { "CMAKE_BUILD_TYPE": "Debug" }
    },
    {
      "name": "x86-release",
      "displayName": "x86 Release",
      "description": "Target Windows (32-bit) with the Visual Studio development environment. (RelWithDebInfo)",
      "inherits": "x86-debug",
      "cacheVariables": { "CMAKE_BUILD_TYPE": "Release" }
    }
  ]
}

我对 cmake install 前缀感兴趣，它是通过该installDir字段设置的。这很好，因为结果目录将间接包含处理器名称“x64”，因为预设名称包含处理器。

但处理器名称是硬编码的，即它是字符串文字的一部分，例如"x64-debug"，在各种预设名称中。是否可以在 CMakePresets.json 中将处理器引用为变量（或宏扩展）？CMAKE_SYSTEM_PROCESSOR即类似于CMakeLists.txt 中可用的缓存变量的东西？

我正在尝试创建一个共享库，libfunc.so它依赖于另一个共享库（具体来说libuv.so，但我认为特定库与问题无关）。即当我运行时ldd libfunc.so，我想查看从libfunc.so到 的依赖关系libuv.so。

这是我想要编译的代码libfunc.so：

#include <uv.h>

int func() {
  uv_timespec64_t now;

  uv_clock_gettime(UV_CLOCK_REALTIME, &now);

  return 0;
}

...我这样编译：

$ cc --version && cc -fpic -ggdb -Wall -c -o func.o func.c
cc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cc -shared -o libfunc.so func.o -fpic -ggdb -Wall -luv
$

...当我运行时ldd libfunc.so，我没有看到所需的依赖项libuv.so：

$ ldd ./libfunc.so
        linux-vdso.so.1 (0x00007fff827ae000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f14b291e000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f14b2b54000)
$

...即我想看到类似的内容：

        linux-vdso.so.1 (0x00007ffcbbdca000)
        libuv.so.1 => /lib/x86_64-linux-gnu/libuv.so.1 (0x00007f781b25c000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f781b034000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f781b2a2000)

我的问题是：为什么没有libuv.so出现依赖关系，我需要做什么才能创建该依赖关系？

我的理解可能是初级和不完整的，但我认为创建依赖关系的方式是：1）编写从（共享）库调用函数的代码，2）编译目标代码，3）创建（共享）库与定义丢失符号的库链接时的目标代码。

检查时libfunc.so，我确实看到了预期的未定义符号libuv：

$ nm libfunc.so | grep U
0000000000002000 r __GNU_EH_FRAME_HDR
                 U __stack_chk_fail@GLIBC_2.4
                 U uv_clock_gettime
$

对于某些上下文，我尝试从较大的项目创建 MVCE。具体来说，该较大的项目创建一个依赖于libuv. 不过，当我ldd在较大项目的共享库上运行时，它确实显示了对libuv（这就是我获得上面“所需”ldd 输出的输出）的依赖关系。

较大的项目太大了，我无法在 Stack Overflow 上发布，但通过检查其make输出，我相信我的 MCVE 正在使用相同的标志进行编译/链接。例如，来自较大项目的一些编译行和链接行是：

cc -fpic -ggdb -Wall   -c -o file1.o file1.c
cc -fpic -ggdb -Wall   -c -o file2.o file2.c
cc -shared -o libplugin.so file1.o file2.o -fpic -ggdb -Wall -luv

（还有更多编译的文件包含libplugin.so，但上面的子集传达了它的要点——所有编译文件的编译标志都是统一的）

更新：如果我在共享库的代码中添加调用uv_close()，则会显示所需的依赖关系！IE：

#include <uv.h>

int func() {
  uv_timespec64_t now;

  uv_clock_gettime(UV_CLOCK_REALTIME, &now);
  uv_close(NULL, NULL); // <= Adding this line causes the desired dependency to show up in ldd

  return 0;
}

$ cc -fpic -ggdb -Wall -c -o func.o func.c
$ cc -shared -o libfunc.so func.o -fpic -ggdb -Wall -luv
$ ldd ./libfunc.so
        linux-vdso.so.1 (0x00007ffc1e323000)
        libuv.so.1 => /lib/x86_64-linux-gnu/libuv.so.1 (0x00007f412b761000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f412b539000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f412b7a1000)
$

有人可以帮助我理解这个观察结果吗？为什么调用uv_clock_gettime()vs.uv_close()对于共享库中创建的依赖关系会有这样的行为？

更新：我想探索@WeatherVane 的评论回复：进一步优化。在这里，我的理解可能是初级和不完整的，但我认为如果我用 进行编译-O0，它将迫使编译器不优化任何内容，因此即使我的共享库仅调用uv_clock_gettime(). 但现实与这个想法不符：返回func.c到仅使用 调用uv_clock_gettime()和编译所有内容-O0，我仍然认为没有对 的依赖libuv。IE：

$ cc -fpic -ggdb -O0 -Wall -c -o func.o func.c # Note the -O0
$ cc -shared -O0 -o libfunc.so func.o  -fpic -ggdb -luv # Note the -O0
$ ldd ./libfunc.so
        linux-vdso.so.1 (0x00007fff8e724000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fee6f03e000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fee6f274000)

我想探索 @Barmar 的建议，即通过打印 的值来排除优化的可能性now，但即使该版本的代码也导致不存在所需的依赖关系。IE：

#include <inttypes.h>
#include <stdio.h>
#include <uv.h>

int func() {
  uv_timespec64_t now;

  uv_clock_gettime(UV_CLOCK_REALTIME, &now);
  printf("%" PRId64 "\n", now.tv_sec);

  return 0;
}

$ cc -fpic -ggdb -Wall -c -o func.o func.c
$ cc -shared -o libfunc.so func.o  -fpic -ggdb -luv
$ ldd ./libfunc.so
        linux-vdso.so.1 (0x00007ffd72bdf000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0a89964000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f0a89b9a000)

探索@EmployedRussian的建议，readelf输出是：

$ readelf -Ws /usr/local/lib/libuv.so.1 | grep uv_close
   337: 0000000000013766   427 FUNC    GLOBAL DEFAULT   14 uv_close
   735: 0000000000013766   427 FUNC    GLOBAL DEFAULT   14 uv_close
$ readelf -Ws /usr/local/lib/libuv.so.1 | grep uv_clock_gettime
   341: 00000000000136a0   178 FUNC    GLOBAL DEFAULT   14 uv_clock_gettime
  1120: 00000000000136a0   178 FUNC    GLOBAL DEFAULT   14 uv_clock_gettime
$

我正在根据 @EmployedRussian 的答案更新一些观察结果，因为它们是相关的，但作为评论添加起来很麻烦。

对于仅调用 的共享库版本uv_clock_gettime，链接器选项的使用-y显示：

$ cc -shared -Wl,-y,uv_clock_gettime,-y,uv_close -o libfunc.so func.o  -fpic -ggdb -luv
/usr/bin/ld: func.o: reference to uv_clock_gettime
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/libuv.so: definition of uv_close
$

uv_clock_gettime...并且对于引用和 的共享库版本uv_close，链接器-y选项显示：

$ cc -shared -Wl,-y,uv_clock_gettime,-y,uv_close -o libfunc.so func.o  -fpic -ggdb -luv
/usr/bin/ld: func.o: reference to uv_close
/usr/bin/ld: func.o: reference to uv_clock_gettime
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/libuv.so: definition of uv_close

...这与@EmployedRussian 对引用的符号与找到的符号与. 的解释一致DT_NEEDED。

此外，对于仅引用的共享库版本uv_clock_gettime，使用链接器--no-as-needed标志确实“强制”包含依赖项：

$ cc -shared -Wl,--no-as-needed -o libfunc.so func.o  -fpic -ggdb -luv
$ ldd ./libfunc.so
        linux-vdso.so.1 (0x00007ffe312cf000)
        libuv.so.1 => /lib/x86_64-linux-gnu/libuv.so.1 (0x00007f36fe4f8000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f36fe2d0000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f36fe538000)
$

void* operator new(std::size_t)为什么在全局范围内定义不会导致多重定义链接错误？

例如，下面的代码可以编译并运行，但我想 libstdc++ 必须定义一个具有相同名称和签名的全局范围函数，不是吗？

// main.cpp

#include <iostream>
#include <new>

void* operator new(std::size_t size) {
    std::cout << "Custom new called for size: " << size << " bytes" << std::endl;

    // Call malloc to allocate memory.
    void* ptr = std::malloc(size);

    return ptr;
}

int main() {
    int* p = new int;
    double* q = new double[10];

    delete p;
    delete[] q;

    return 0;
}

$ g++ --version && g++ -g ./main.cpp && ./a.out
g++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Custom new called for size: 4 bytes
Custom new called for size: 80 bytes