LINUX.ORG.RU

Ошибка при линковке shared библиотеки при использовании cmake

 , ,


0

3

Имею проект с такой структурой

* test_dpi
  * dpi
    * include
      * typedefs.h
      * streams.h
    * src
      * typedefs.cpp
      * streams.cpp
    * CMakeLists.txt
  * main.cpp
  * CMakeLists.txt

typedefs.h

#pragma once

#include <iostream>
#include <vector>

#define DECLARE_SERIALIZATION template<typename Ar> void serialize(Ar& ar, const unsigned version);

namespace DPI
{
    enum class Direction : int {
        Forward = 1,
        Reverse
    };

    struct Flow {
        uint64_t id{};

        DECLARE_SERIALIZATION
    };

    struct Packet {
        uint64_t flow_id{};

        DECLARE_SERIALIZATION
    };

    struct Dump {
        std::vector<Packet> packets;
        std::vector<Flow> flows;

        DECLARE_SERIALIZATION
    };
}

streams.h

#pragma once

#include "typedefs.h"

#include <boost/filesystem.hpp>
#include <boost/archive/binary_wiarchive.hpp>
#include <boost/archive/binary_woarchive.hpp>

namespace DPI
{
    bool load(const std::wstring& path, Dump& dump);
    bool dump(const std::wstring& path, const Dump& dump);
}

main.cpp

#include "dpi/streams.h"

int main() {
    std::cout << "Hello, World!" << std::endl;

    DPI::Dump dump;
    DPI::dump(L"this.bin", dump);

    return 0;
}

dpi/CMakeLists.txt

cmake_minimum_required(VERSION 3.12)
project(dpi)

add_library(dpi SHARED
        include/dpi/typedefs.h include/dpi/streams.h
        src/typedefs.cpp src/streams.cpp
        )

target_include_directories(dpi PRIVATE ./include/dpi)

CMakeLists.txt

cmake_minimum_required(VERSION 3.13)
project(test_dpi)

set(CMAKE_CXX_STANDARD 17)
find_package(Boost REQUIRED)

add_subdirectory(dpi)
include_directories(${dpi_SOURCE_DIR}/include)

add_executable(test_dpi main.cpp)
link_libraries(test_dpi boost_system boost_serialization boost_wserialization dpi)

Сам подпроект компилируется нормально, но при попытке собрать test_dpi в терминале появляются такие ошибки

====================[ Build | test_dpi | Debug ]================================
/opt/clion-2018.3.1/bin/cmake/linux/bin/cmake --build /home/ramb/Projects/test_dpi/cmake-build-debug --target test_dpi -- -j 2
[ 50%] Linking CXX executable test_dpi
/usr/bin/ld: CMakeFiles/test_dpi.dir/main.cpp.o: in function `main':
/home/ramb/Projects/test_dpi/main.cpp:9: undefined reference to `DPI::dump(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, DPI::Dump const&)'
/usr/bin/ld: CMakeFiles/test_dpi.dir/main.cpp.o: in function `boost::system::error_category::std_category::equivalent(int, std::error_condition const&) const':
/usr/include/boost/system/error_code.hpp:676: undefined reference to `boost::system::generic_category()'
/usr/bin/ld: /usr/include/boost/system/error_code.hpp:679: undefined reference to `boost::system::generic_category()'
/usr/bin/ld: CMakeFiles/test_dpi.dir/main.cpp.o: in function `boost::system::error_category::std_category::equivalent(std::error_code const&, int) const':
/usr/include/boost/system/error_code.hpp:706: undefined reference to `boost::system::generic_category()'
/usr/bin/ld: /usr/include/boost/system/error_code.hpp:709: undefined reference to `boost::system::generic_category()'
/usr/bin/ld: /usr/include/boost/system/error_code.hpp:721: undefined reference to `boost::system::generic_category()'
collect2: error: ld returned 1 exit status
gmake[3]: *** [CMakeFiles/test_dpi.dir/build.make:84: test_dpi] Error 1
gmake[2]: *** [CMakeFiles/Makefile2:73: CMakeFiles/test_dpi.dir/all] Error 2
gmake[1]: *** [CMakeFiles/Makefile2:85: CMakeFiles/test_dpi.dir/rule] Error 2
gmake: *** [Makefile:118: test_dpi] Error 2

Что я делаю не так?


Ответ на: комментарий от WatchCat

Это не значит что я не перепробовал предложенные советы

Ram-B
() автор топика
Ответ на: комментарий от slovazap

RedHat’ом можно разве что подтереться, как и твоим неосиляторским мнением.

Неосиляторы это code monkeys из Kitware, делающие CMake и на ходу меняющие свои решения вследствии неадекватного изначального проектирования:

https://github.com/Kitware/CMake/pull/152/files

Достаточно сравнить сколько проектов у вас с редхатом в сумме и сколько проектов используют CMake.

Фанатики autocrap’ов говорили тоже самое.

EXL ★★★★★
()
Ответ на: комментарий от EXL

Неосиляторы это code monkeys из Kitware

Ну начнём с того что чтобы кого-то code monkeys называть ты должен быть кем-то, а ты никто.

делающие CMake и на ходу меняющие свои решения вследствии неадекватного изначального проектирования:

Это аргумент капризного трехлетнего ребёнка - «папа обещал в зоопарк и не сводил, нююю», только вам ничего не обещали. Инструкции для обнаружения зависимостей должны писаться авторами этих самых зависимостей и с ними поставляться, и никак иначе. Ни в комплекте CMake, ни в отдельном репозитории про которй ты бредишь в соседней теме их быть не должно ни в каком виде, потому что они не будут поддерживаться, разъедутся и потеряют совместимость и с апстримом и с даунстримом, и в итоге будут дёргаться в каждый репозиторий, и правиться локально, как сейчас те FindSDL2_mixer.cmake. И нет, версионирование никак не поможет.

Фанатики autocrap’ов говорили тоже самое

Не спорю что CMake чем-то заменится, но пока нечем. Может meson решил проблему детекта зависимостей? Хрен там был:

https://mesonbuild.com/Dependencies.html

Он умеет pkg-config и cmake файлы, т.е. не просто то же самое что cmake, но и явно зависит от его наработок, своих не имея.

Вижу небольшой список «Dependencies with custom lookup functionality». Да-да, как и у CMake. И если он наберёт хоть какую-то популярность, и туда начнут пытаться добавить скрипты для всего подряд, закончится это таким же отлупом.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Ни в комплекте CMake, ни в отдельном репозитории про которй ты бредишь в соседней теме их быть не должно ни в каком виде, потому что они не будут поддерживаться

Так и запишем:

Разработчики CMake из Kitware неосиляторы и не осилили ту работу, которой уже десятки лет занимаются весьма успешно и продуктивно мейнтейнеры различных Linux- и UNIX-дистрибутивов.

Инструкции для обнаружения зависимостей должны писаться авторами этих самых зависимостей и с ними поставляться, и никак иначе.

Ситуация аналогичная бредятине «разработчик ПО должен сам собирать пакеты под Debian, Ubuntu, Fedora, CentOS/RHEL и писать ebuld’ы под Gentoo и ArchLinux».

Да ещё и вредная, учитывая этот CMake-мусор в кодовых базах различных проектов.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 2)
Ответ на: комментарий от EXL

Разработчики CMake из Kitware неосиляторы и не осилили ту работу, которой уже десятки лет занимаются весьма успешно и продуктивно мейнтейнеры различных Linux- и UNIX-дистрибутивов.

Это какую же? Ни один дистрибутив ещё не осилил поддержать у себя полный комплект файлов детектирования всех библиотек. Ни один такого даже не начал. Всё что сделали дистрибутивы - написали списки зависимостей, причём местами криво, а детектится и собирается всё как и собиралось, системами сборки. Из которых CMake пока справляется лучше всех.

Ситуация аналогичная бредятине «разработчик ПО должен сам собирать пакеты под Debian, Ubuntu, Fedora, CentOS/RHEL и писать ebuld’ы под Gentoo и ArchLinux».

Ничего общего. В отличие от зоопарка пакетов, которые не собрать без зоопарка дистрибутивов, он должен сделать один файл, который будет использоваться всеми. На самом деле даже делать его не нужно, CMake сам сделает, для этого нужно только добавить одну строчку install(EXPORT)

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Разработчики CMake из Kitware неосиляторы и не осилили ту работу

Это какую же?

Ту, которую они начинали, радостно визжа в списках рассылки о том, как хорошо и удобно использовать CMake вкупе с зависимостями, но потом смачно обдристались в середине пути, создав ещё больше всем проблем. Неосиляторы. Стыдоба.

Из которых CMake пока справляется лучше всех.

Справлялся, пока они бандлили. Говорить нужно в прошедшем времени, ибо теперь CMake с этой помойкой из устаревших и заскорузлых FindModule’ей +/- такая же дрянь, как и autocrap’ы с их libtool/pkg-config ахинеей.

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

Самая что ни на есть общая. Вместо зоопарка пакетов из-за CMake теперь в каждой кодовой базе зоопарк из разных кривоработающих FindModule’ей, делающих одно и то же. Вместо того, чтобы провести стандартизацию и наладить версионирование, эти неосиляторы развели ещё больший зоопарк.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от EXL

Ту, которую они начинали, радостно визжа в списках рассылки о том, как хорошо и удобно использовать CMake вкупе с зависимостями, но потом смачно обдристались в середине пути, создав ещё больше всем проблем. Неосиляторы. Стыдоба.

Что они в списках рассылки они обещали я не знаю (и тебе свистуну на слово что они что-то обещали конечно же не поверю), но по факту то что они не стали бандлить больше модулей - это однозначный вин. И то что они создали самую продвинутую систему сборки на текущий момент, это тоже вин.

Справлялся, пока они бандлили.

Нет, всегда. Потому что бандлили они, прямо скажем, мало, а писать Find модули, прямо скажем, просто и приятно, так что их писали всегда и бед не знали. И при этом они работают везде. В любом случае Meson, да и никто, ничего лучшего пока не сделали, и максимум на что их хватило - использовать ненавистные тебе cmake модули и pkg-config. Вот это и называется обдристаться.

Вместо того, чтобы провести стандартизацию и наладить версионирование, эти неосиляторы развели ещё больший зоопарк

Прямым текстом было сказано что никакое версионирование тут никому не поможет. Стандартизация возможна только в апстримах, а насильно туда не залезешь, но настолько активно насколько это в принципе возможно она идёт, и идёт именно за счёт CMake - я в /usr/local/lib/cmake вижу уже дофига родных модулей поставляемых с библиотеками. А для того чего там нет модуль всегда можно написать из двух строчек, и он будет работать.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Он умеет pkg-config и cmake файлы, т.е. не просто то же самое что cmake, но и явно зависит от его наработок, своих не имея.

Ай-яй-яй! Не делает новый конкурирующий стандарт, а пытается использовать уже сделанную другими работу! Какой кошмар! Срочно запретить!

i-rinat ★★★★★
()
Ответ на: комментарий от slovazap

Нет, всегда. Потому что бандлили они, прямо скажем, мало

Популярные библиотеки они покрывали. Теперь – не покрывают. А старые, никому не нужные либы, вроде SDL1 и Qt4, внезапно, покрывают. И это не зоопарк?

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

Можешь мне не демонстрировать свой фанатизм, на меня он никак не действует.

а писать Find модули, прямо скажем, просто и приятно, так что их писали всегда и бед не знали

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

Писать эти Find модули должны профессионалы и компетентные люди, которые вкурсе особенностей различных популярных операционных систем, Linux-дистрибутивов. Иначе получается такое говно:

  1. FindSDL2_mixer.cmake
  2. FindSDL2_mixer.cmake
  3. FindSDL2_mixer.cmake
  4. FindSDL2_mixer.cmake
  5. FindSDL2_mixer.cmake

А вот если бы модули были в комплекте или хотя бы был бы community-driven репозиторий с ними, волосы использующих CMake людей были бы гладкими и шелковистыми, вместо постоянного переписывания этих модулей или ситуации:

Каждый день я хожу по GitHub’у с черным мешком для мусора и собираю в него все Find модили, которые нужны для моих проектов. На два разных проекта целый день уходит.

Но неосиляторы-разработчики CMake не смогли продолжить своё же хорошее начинание.

EXL ★★★★★
()
Ответ на: комментарий от EXL

Популярные библиотеки они покрывали. Теперь – не покрывают. А старые, никому не нужные либы, вроде SDL1 и Qt4, внезапно, покрывают. И это не зоопарк?

Нет. Можно считать что ничего не покрывают, и это правильно. А легаси он и в африке легаси.

Можешь мне не демонстрировать свой фанатизм, на меня он никак не действует.

Не действовал бы - ты бы не отвечал. А так я вижу что действует и ответить тебе нечего.

Это до тех пор, пока проект не потребуется скомплировать под другую операционную систему или другое окружение, другой дистрибутив со сильно отличающейся структурой

Я постоянно собираю софт под FreeBSD - если что она значительно отличается от линуксов, куда сильнее чем линуксы между собой. И CMake - единственная система сборки которая собирает под неё из коробки, не требуя правки сборочного кода, а если требуя то минимальных. Я давно публиковал тут статистику, в объёме патчей на CMakeLists против autocrap (на порт, использующий соответствующую систему), разница была на порядок. Можно было бы и с meson сравнить, но пока его слишком мало кто использует. Посмотрел навскидку несколько портов - везде используются патчи для meson.build. Fail.

Писать эти Find модули должны профессионалы и компетентные люди

Я повторюсь, писать Find модули вообще никто не должен. Их пишет сам CMake, и они работают всегда. Но для этого их должны включить в апстриме. Пока этого не произошло, их будут писать потребители этих библиотек, и никакой проблемы в этом нет, потому что модуль это две строчки find_library и find_path, ну и опциональная обвязка из сообщений и mark_as_advanced, которой собственно они и отличаются и которая ни на что не влияет. А таких профессионалов о которых ты говоришь не существует, не говоря даже об объёмах поддержки всех версий всех библиотек.

А вот если бы модули были в комплекте или хотя бы был бы community-driven репозиторий с ними

Я ещё раз повторяю, слепая ты тетеря, ни в комплекте cmake, ни в виде отдельного репозитория существовать эти модули не могут в принципе, осознай это. Потому что во-первых, поддерживать это некому, во-вторых, оно принципиально не может быть синхронизировано ни с апстримами, ни с даунстримами, поэтому неработоспособно.

Короче, даже не надейся - пути к счастью кроме агитации апстримов к установке export файлов нет и не предвидится.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Я ещё раз повторяю, слепая ты тетеря, ни в комплекте cmake, ни в виде отдельного репозитория существовать эти модули не могут в принципе, осознай это.

https://github.com/Kitware/CMake/tree/master/Modules

Ctrl+F «Find»

Видимо показалось. Это к вопросу о слепоте.

EXL ★★★★★
()
Ответ на: комментарий от Ram-B

всё нормально линкуется если использовать не binary_wiarchive и binary_woarchive, а binary_iarchive и binary_oarchive

Больше даблов богу даблов!

...Вот за это мы её и не любим.

Хочу что-нибудь вида

project Calculator (C++, executable)
{
    sources-with-includes {
        engine.cpp,
        statlib.cpp
    },
    sources {
        main.cpp
    },
    includes {
        calcdefs.h
    },
    static-deps {
        gmp
    }
}

И так далее. Да, при необходимости предусмотреть ключевые слова для разруливания номеров версий, условной сборки. И чтобы било по рукам при ошибках ещё до запуска компилятора.

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 2)
Ответ на: комментарий от hobbit

Очень похоже на gyp. Как только проект становится сложнее hello word, и его конфиг перестает помещаться на одну страницу, начинается ад из-за вложенных скобочек

anonymous
()
Ответ на: комментарий от hobbit

Есть ещё такая интересная штука, как waf: https://waf.io/book/

Пример использования в реальном проекте:

https://github.com/FWGS/xash3d-fwgs/blob/master/wscript

Ещё он бутстрапится и для сборки проекта с его помощью никакого waf устанавливать не нужно, только Python, который есть почти везде. Этот подход похож на Gradle’овский. А сами скрипты сборки тоже на Python, что выглядит довольно интересно.

EXL ★★★★★
()
Ответ на: комментарий от anonymous

Этот? Да, похоже. :)

Хотя я бы всё-таки отошёл бы ещё чуть-чуть от «чисто JSON» в сторону ещё большей лаконичности, C-подобности и строгости. Я правильно понимаю, что если в gyp ошибиться в имени одного из узла, система ничего не скажет (это же просто имя, а не ключевое слово)?

И статья на хабре 2013 года. Оно умерло? Хотя... Если это используется для сборки Хромиума... Хм...

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от hobbit

Да, практически умер. Google, который его использовал для сборки своих проектов его забросил. Вместо него теперь используют ng (ninja generator). Когда в последний раз смотрел тот же хромиум, гугловцы активно переводили остатки гиповских файлов в ng.

Ошметки gyp остались в ввиде проекта node-gyp, которым рекомендуют собирать аддоны для nodejs. Да и сама нода собиралась при помощи gyp (скорее всего, это сложилось исторически - когда начинали разрабатывать ноду, JS движок v8 был частью проекта хромиум и поэтому собирался gyp).

В других местах я gyp не встречал. Дурацкий синтаксис, абсолютно никчемная и неполная документация (шаг вправо, шаг влево - берешь отладчик и начинаешь дебажить его питоновские исходники), заточенность в первую очередь под хромиум. В общем, никому не советую.

anonymous
()
Ответ на: комментарий от EXL

Есть ещё такая интересная штука, как waf

Это от которого у мейнтейнеров смачно горит? Было бы любо дорого посмотреть, если бы он взлетел.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.