Неопределенная ссылка с std :: эксперимент :: необязательно, несмотря на наличие символа

Question

После того, как я поковырялся с кучей настроек CMake в проекте, над которым я работаю, я столкнулся с проблемой компоновки, с которой раньше не сталкивался.

В двух словах, у меня есть состояние c библиотека (.a файл) со следующим символом (demangled):

00000000000018e0 g     F .text  0000000000000690 std::experimental::fundamentals_v1::optional<int> monetdb::gdk::buffer_pool::find_column<(monetdb::column_name_kind)2>(monetdb::column_name<(monetdb::column_name_kind)2> const&) const

, но когда я пытаюсь связать исполняемый файл с этим файлом и скомпилированным исходным кодом, используя этот метод, я получаю:

main.cpp:(.text+0x6950): undefined reference to `std::experimental::optional<int> monetdb::gdk::buffer_pool::find_column<(monetdb::column_name_kind)2>(monetdb::column_name<(monetdb::column_name_kind)2> const&) const'

Это единственная и единственная ошибка компоновки, хотя я создаю buffer_pool и использую кучу других методов. С другой стороны, это также единственный шаблонный метод в классе.

Каковы потенциальные причины такой ошибки, учитывая наличие символа в библиотеке?

Моя единственная пока "подсказка" в том, что имя необязательного класса разные: std::experimental::optional против std::experimental::fundamentals_v1::optional. Может ли это быть причиной?

Примечания:

• Я спрашиваю о потенциальных причинах, а не фактических причинах (которые вы не могу определить без отдельного примера).
• Я явно создаю экземпляр этого шаблонного метода, просто чтобы быть в безопасности.
• Используется компиляция g ++ 8.3.0 и /usr/bin/ld 2.32.51.
• Я нахожусь на Devuan 3 Beowulf (~ = Debian 10 Buster без systemd).

• Результат g++- v:

  Using built-in specs.
  COLLECT_GCC=g++-8
  COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
  OFFLOAD_TARGET_NAMES=nvptx-none
  OFFLOAD_TARGET_DEFAULT=1
  Target: x86_64-linux-gnu
  Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-22' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto --enable-link-mutex
  Thread model: posix
  gcc version 8.3.0 (Debian 8.3.0-22) 
  

Answer 1

tl; dr: Это может быть вызвано использованием пользовательской реализации optional в коде вне библиотеки.

Моя догадка была верна, но комментарии @ 1201ProgramAlarm привели меня к решению:

Определение std::experimental::optional в проекте с использованием библиотеки stati c не было взято из стандартной библиотеки C ++. Вместо этого это было затенено необязательной реализацией Анджея Кшеменского . Теперь мне нечего сказать об этом - это действительно приятно; однако оно помещает это определение в std::experimental, что означает, что если вы не будете осторожны, вы можете принять его за C 101 14 std::experimental::optional.

В моем случае цепочка #if __cplusplus > something определите это одним способом, #else if __cplusplus > something else определите это другим способом и c. был неисправен - Пользовательская необязательная реализация использовалась даже при компиляции с C ++ 14.

Компоновщик, с другой стороны, не путает различные реализации optional; на самом деле, std::experimental::optional в libstdc ++ - это просто псевдоним для std::experimental::fundamentals_v1::optional<int>; поэтому искаженное имя для функции, возвращающей optional<int>, отличается. Таким образом, даже несмотря на то, что в C ++ вы не можете перегружать функцию возвращаемого типа, то есть никакие две функции не могут иметь одинаковую сигнатуру, за исключением другого возвращаемого типа - ничто не мешает двум именам искаженных функций быть такими (IIANM), и это действительно, что произошло в моем случае.

В чем я сейчас не совсем уверен, так это в том, как я вообще избежал проблемы со связыванием ...