StoneThrow's questions

Estou em um ambiente de compilação cruzada em que meu projeto precisa ser compilado para Linux, Windows e um destino personalizado, que é compilado cruzado no Windows.

O projeto usa o googletest para testes de unidade e está incluído da seguinte forma, em um arquivo find do CMake, como segue:

# 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()

As compilações do Windows e Linux não são compiladas cruzadamente e compilam bem. Mas para o alvo personalizado, recebo os seguintes erros de compilação (editados para legibilidade):

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'

Como posso passar por esses erros de compilação para meu destino de compilação cruzada?
Existe uma maneira de fazer isso fornecendo a combinação certa de macros para a compilação (por exemplo, com add_definition()instruções CMake)?
Ou devo criar uma versão personalizada do gtest? Ou seja, imagino que isso significa que não devo usar FetchContent_Declare()/ FetchContent_MakeAvailable()ou find_package()incluir googletest, mas sim ter googletest como um subdiretório do meu projeto, possivelmente com alterações de código para contornar o uso das funções indefinidas(?)

O seguinte CMakePresets.json demonstra a imposição de que uma variável de ambiente seja definida usando condições 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
$

A seguinte modificação mostra que a condição pode ser herdada:

{
  "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
$

Mas a herança da condição dos pais parece desaparecer se a herança de ConditionPresets introduzir sua própria condição:

{
  "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
$

Existe uma maneira de implementar um relacionamento "e" entre as condições implementadas no configurePreset atual e as condições de um configurePreset herdado?
Quero inherited_presetimpor a condição que ${hostSystemName}é "Linux" e que o ambiente pai define FOO.
A documentação do CMake Presets indica uma allOfpalavra-chave, mas não dá um exemplo de como usá-la, e não descobri como usá-la para implementar minha necessidade.

Abaixo estão minhas duas tentativas de interpretar a partir da documentação como usar 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"
            }
          ]
        }
      }
    }
  ]
}

... mas ambas as tentativas falharam na análise com o mesmo erro:

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

Atualização: acho que tive um mal-entendido na minha tentativa anterior de usar o allOf. A tentativa a seguir analisa, mas ainda não consegue implementar o comportamento desejado de impor as condições da criança e dos pais:

{
  "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
$

O Visual Studio gerou o seguinte CMakePresets.json para mim quando clico em "Gerenciar configurações..." em um projeto CMake:

{
  "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" }
    }
  ]
}

Estou interessado no prefixo de instalação cmake, que é definido com o installDircampo. É bom porque o diretório resultante incluirá indiretamente o nome do processador "x64", já que o nome predefinido inclui o processador.

Mas o nome do processador é codificado, ou seja, faz parte da string literal, por exemplo "x64-debug", nos vários nomes predefinidos. É possível referenciar o processador como uma variável (ou expansão de macro) em CMakePresets.json? Ou seja, algo semelhante à CMAKE_SYSTEM_PROCESSORvariável de cache que está disponível em CMakeLists.txt?

Estou tentando criar uma biblioteca compartilhada, libfunc.soque depende de outra biblioteca compartilhada (especificamente libuv.so, mas acho que a biblioteca específica não é relevante para a questão). Ou seja, quando executo ldd libfunc.so, quero ver a dependência de libfunc.sopara libuv.so.

Este é o código que quero compilar libfunc.so:

#include <uv.h>

int func() {
  uv_timespec64_t now;

  uv_clock_gettime(UV_CLOCK_REALTIME, &now);

  return 0;
}

... eu compilo assim:

$ 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
$

...quando executo ldd libfunc.sonão vejo a dependência desejada em 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)
$

... ou seja, eu queria ver algo como:

        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)

Minha pergunta é: por que não libuv.soaparece uma dependência e o que preciso fazer para criar essa dependência?

Meu entendimento é provavelmente rudimentar e incompleto, mas pensei que criar um relacionamento de dependência seria algo como 1) escrever código que chama uma função de uma biblioteca (compartilhada), 2) compilar código de objeto, 3) criar biblioteca (compartilhada) de código de objeto ao vincular a uma biblioteca que define o símbolo ausente.

Inspecionando libfunc.so, vejo símbolos indefinidos esperados para libuvsímbolos:

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

Para algum contexto, estou tentando criar um MVCE a partir de um projeto maior. Especificamente, esse projeto maior cria uma biblioteca compartilhada que depende do libuv. Porém , quando executo ldda biblioteca compartilhada do projeto maior, ela mostra uma dependência libuv(foi aí que obtive a saída para a saída ldd "desejada", acima).

O projeto maior é muito grande para eu postar aqui no Stack Overflow, mas ao inspecionar sua makesaída, acredito que meu MCVE está compilando/vinculando com os mesmos sinalizadores. Por exemplo, algumas linhas de compilação e a linha de link do projeto maior são:

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

(há mais arquivos compilados que compõem libplugin.so, mas o subconjunto acima transmite a essência disso - os sinalizadores de compilação são uniformes para todos os arquivos compilados)

Atualização: se eu adicionar uma chamada uv_close()no código da minha biblioteca compartilhada, o relacionamento de dependência desejado aparecerá! Ou seja:

#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)
$

Alguém pode me ajudar a entender essa observação? Por que chamar uv_clock_gettime()vs. uv_close()se comporta dessa maneira em relação ao relacionamento de dependência criado na biblioteca compartilhada?

Atualização: eu queria explorar um pouco mais o comentário de @WeatherVane sobre RE: otimização. Aqui, novamente, meu entendimento é provavelmente rudimentar e incompleto, mas pensei que se eu compilasse com -O0, isso forçaria o compilador a não otimizar nada e, portanto, induziria a dependência mesmo quando minha biblioteca compartilhada chamasse apenas uv_clock_gettime(). Mas a realidade não correspondeu a essa ideia: voltando func.ca apenas chamar uv_clock_gettime()e compilar tudo com o -O0, ainda não vejo dependência do libuv. Ou seja:

$ 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)

Eu queria explorar a sugestão do @Barmar de excluir a possibilidade de otimização imprimindo o valor de now, mas mesmo essa versão do código resultou em não haver a dependência desejada. Ou seja:

#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)

Explorando a sugestão de @EmployedRusso, o readelfresultado é:

$ 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
$

Estou atualizando esta postagem com algumas observações baseadas na resposta de @EmployedRusso porque são relevantes, mas difíceis de adicionar como comentário.

Com a versão da biblioteca compartilhada que chama apenas uv_clock_gettime, o uso da -yopção vinculador revela:

$ 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
$

... e com a versão da biblioteca compartilhada que faz referência a ambos uv_clock_gettimee uv_close, a -yopção do vinculador revela:

$ 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

... que se alinha com a explicação de @EmployedRusso sobre símbolos referenciados vs. símbolos encontrados DT_NEEDEDvs.

Além disso, com a versão da biblioteca compartilhada que faz referência apenas a uv_clock_gettime, o uso do --no-as-neededsinalizador do vinculador realmente "forçou" a inclusão da dependência:

$ 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)Por que a definição no escopo global não causa um erro de link de definição múltipla?

Por exemplo, o código abaixo compila e executa, mas imagino que libstdc++ deva definir uma função de escopo global com o mesmo nome e assinatura, não?

// 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