LINUX.ORG.RU

Перенос SFML-Проекта С++ с Windows на Linux

 , , ,


0

1

Здравствуйте! Возникла необходимость переноса моего С++ проекта на Linux с возможностью дальнейшей разработки. Использовалась лишь одна несистемная библиотека (SFML) + Windows.h, всё остальное итак есть в Линуксе. После удачной установки и тестирования этой библиотеки в среде Qt Creator, я решил сделать перенос файлов того проекта. Файлов всего 5 включая main.cpp

После переноса и подмены некоторых функций и библиотек столкнулся с такими вот ошибками:

1)Space.o: undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'

2)error adding symbols: DSO missing from command line

3)collect2: error: ld returned 1 exit status

Как с этим быть?

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

Не посчитайте профаном, но я у меня не получается найти место куда именно нужно это добавлять в Qt Creator? Не получается найти настройки линковщика

alex_fmv
() автор топика
Ответ на: комментарий от alex_fmv

А какой именно системой сборки вы пользуетесь? QMake или CMake?

Если QMake, то добавьте в .pro-файл своего проекта:

CONFIG += thread

А если CMake, то добавьте в CMakeLists.txt что-то вроде:

find_library(PTHREAD_LIBRARY pthread)
# ... 
target_link_libraries(main ${PTHREAD_LIBRARY})
EXL ★★★★★
()
Ответ на: комментарий от EXL

Да, это действительно помогло, спасибо огромное

alex_fmv
() автор топика

Очень странно... Если ты подключаешь SFML через CMake, то там не требуется никаких телодвижений, все зависимости уже прописаны. А qmake уже потихоньку в гроб ложат.

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

Уж лучше CMake, чем qmake.

Так-то можно и Meson использовать, но интеграции у Qt Creator (на февраль 2019-го) с ним нет.
А вот у GNU autotools интеграция есть, потому может и для Meson тоже будет в будущем.

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

CMake – говно

Платиновые слова, воистину так. См, выше: QBS? Meson? Что есть наше будущее? Хотя qmake мне до сих пор нравится, видимо проекты у меня примитивные.

I-Love-Microsoft ★★★★★
()

Если не прибивал гвоздями прогу к оффтопику (Windows.h не считается :)), то портирование тривиально. Которые тут тебя агитируют за мезон — лукавые еретики. meson == python to build cpp == heresy.

По правде, твой проЭкт не должен зависеть от того, какая у тебя система сборки. Т.е. норм должен собираться любым наколеночным скриптом (который например генерит входной файл для make, или $BULDSYSTEMNAME, но зависеть от кучи сторонних зависимостей — это не айс). Добавлять пыхтон для сборки cpp — это болезнь тех которые «знают как надо», а в результате создают «15-й конкурирующий стандарт» — бесило еще при сборке v8, когда «установите питон и пыхтоно зависимости не ниже версий таких-то», которые проекту на cpp вроде как никуда не уперлись. В результате этот ихний GYP уже давно RIP — ну и нафиг тебе такие зависимости, которые зависят от левой пятки уставших сектантов, которые бросают свою поделку не достигнув ни зрелости ни значимой массовости. По той же причине можно крепко подумать, нужно ли Qt и ее среда, которая не так давно валилась при парсинге любого достаточно большого cpp проекта :) Слишком давно они свернули куда-то не туда — вместо фикса перетаскиваемых из релиза в релиз багов.

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

meson == python to build cpp == heresy

Meson не направлен исключительно на C++. Если интересно, почему они выбрали именно Python, то вот.

установите питон и пыхтоно зависимости не ниже версий таких-то

Meson, наоборот, старается минимизировать объём зависимостей.
На данный момент, ему нужен Python 3.5+, Setuptools и ninja. Больше ничего.

Darth_Revan ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Что есть наше будущее?

К сожалению, CMake.

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