LINUX.ORG.RU

Статическая линковка с ImageMagick(GraphicsMagick)

 , , , ,


1

2

Здравствуйте.

Имеется проект с cmake. Надо сбилдить его с ImageMagick, скомпиленным из сорцов, статически.

Собирал ImageMagick так:

./configure --enable-static --disable-shared

После этого получаю либы и пытаюсь линковаться с ними с помощью такого CmakeLists.txt :

cmake_minimum_required(VERSION 3.6)
project(zamlib)

include_directories(include/ include/GraphicsMagick)
link_directories(lib/libjpeg lib/libpng lib/libtiff lib/zlib lib/libjasper
                 lib/libwebp lib/libippcv lib/GraphicsMagick)

set(CMAKE_CXX_STANDARD 14)

set(SOURCE_FILES src/main.cpp)
add_executable(zamlib ${SOURCE_FILES})

#Dependencies

set(GraphicsMagick_LIBS libGraphicsMagick.a libGraphicsMagick++.a)

target_link_libraries(zamlib
        ${GraphicsMagick_LIBS}
        pthread

        libippicv.a
        liblibwebp.a
        liblibjasper.a
        liblibjpeg.a
        liblibpng.a
        liblibtiff.a
        libzlib.a
        )

Но при линковке имею много ошибок с Magick++ (часть из них):

undefined reference to 'GetExceptionInfo'
undefined reference to 'ThrowLoggedException'
undefined reference to 'SetClientName'

Как такое побороть? Находил в Интернете какие-то решения с Magick-config, но как это встроить в cmake?

Сразу отвечу на вопрос - на самом деле работаю с GraphicsMagick, но линковаться они должны вроде как одинаково, так как GraphicsMagick является форком ImageMagick. Если кто-то может обьективно сравнить ImageMagick и GraphicsMagick, тоже прошу высказаться.

Находил в Интернете какие-то решения с Magick-config, но как это встроить в cmake?

Легко, вызвать его через execute_process и заполнить таким образом GraphicsMagick_LIBS, GraphicsMagick_INCLUDE_DIRS, GraphicsMagick__COMPILE_DEFINITIONS и т.п. Find-модули, основанные на pkg-config, делают примерно это же.

annulen ★★★★★ ()

make VERBOSE=1 уже пробовал? Что за команда для сборки на самом деле выполняется? Там ли ищутся нужные библиотеки? Есть ли они там на самом деле?

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

Если это так, то может можно укзатать Find-модулю, где просто искать нужные ему либы, хедеры и т.д. ?

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

Обычно Find-модули используют, когда надо узнать информацию из системы

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

у меня возникает резонный вопрос - а как на винде тогда билдятся статически с imagemagick?

zamazan4ik ★★ ()

Попробуй поменять местами libGraphicsMagick++.a и libGraphicsMagick.a в списке.

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

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

А с чем связана важность порядка линкования?

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

С тем, что по-умолчанию линкер обрабатывает статические библиотеки слева направо, и неиспользуемые символы выкидывает

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

А с чем связана важность порядка линкования?

-Wl,--as-needed

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

--as-needed не имеет отношения к рассматриваемой ситуации

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

Эээ... Почему нет? Делаешь no-as-needed, и порядок снова не важен.

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

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

Вот если продуктом сборки являет динамическая библиотека, то включение --as-needed может поломать сборку ее «клиентов»

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

На статические либы он не влияет

Хм... действительно не влияет.

У меня похожие проблемы всплыли, когда в дистрибутивы завезли новый ld, в котором было включено --as-needed по умолчанию. Возможно, какое-то другое изменение повлияло.

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