Nuke неопределенный символ: _ZN9Imath_2_16Rand325nextfEv

Я собираю плагин для Nuke8 под Linux. Вся компиляция выполняется без проблем, но у меня возникает следующая ошибка при попытке загрузить плагин:

undefined symbol: _ZN9Imath_2_16Rand325nextfEv

Когда я делаю «ldd» на plugin.so, у меня есть это:

linux-vdso.so.1 =>  (0x00007fff44869000)
libDDImage.so => not found
libfftw3f.so.3 => /usr/lib64/libfftw3f.so.3 (0x00007f4609bf5000)
libImath.so.6 => /usr/lib64/libImath.so.6 (0x00007f46099f0000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f46096ea000)
libm.so.6 => /lib64/libm.so.6 (0x00007f4609465000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f460924f000)
libc.so.6 => /lib64/libc.so.6 (0x00007f4608ebb000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4608c9d000)
libIex.so.6 => /usr/lib64/libIex.so.6 (0x00007f4608a7f000)
/lib64/ld-linux-x86-64.so.2 (0x000000300bc00000

Кажется, все lib загружены нормально. У меня есть «libDDImage.so => ​​not found», но это нормально, у меня то же самое, когда я делаю это на примере плагина.

Я думаю, что проблема исходит из библиотеки Imath, но я не знаю, как ее исправить.
У кого-нибудь есть идея? Заранее спасибо.

Лучший

1

Решение

ОБНОВИТЬ

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

Ссылки на скомпилированные бонары и исходные файлы можно найти по адресу: https://www.thefoundry.co.uk/products/nuke/developers/

У них также есть открытый запрос на включение этих изменений в основной проект OpenEXR, который можно найти здесь: https://github.com/openexr/openexr/pull/141

Оригинальный ответ

К сожалению, этот тип проблемы трудно найти, не зная всего о вашей среде сборки и времени выполнения, но вот некоторая информация и идеи, которые, мы надеемся, помогут вам встать на правильный путь.

Подводя итог, я думаю, что это, вероятно, одна из четырех вещей:

  • Проблема с пространством имен символов
  • Проблема двоичной совместимости (из-за несоответствия версий библиотеки)
  • Проблема с загрузкой библиотеки
  • Проблема с версией компилятора

Пространства имен символов

Nuke 8 поставляется с собственными библиотеками EXR 2 (в частности, версия 2.0.1), которые вы можете найти в каталоге установки. Если вы посмотрите на экспортированные символы (используя nm -D), вы можете видеть, что не только символы находятся в пользовательском пространстве имен, но и версия библиотеки отличается от той, с которой вы ссылаетесь.

$ nm -D "/usr/local/Nuke8.0v5/libImath-2_0_1_Foundry.so.10" | grep Rand | c++filt
0000000000012590 T Imath_2_0_1_Foundry::Rand32::nextf()

Как видите, символы EXR 2 в Nuke находятся в пространстве имен Imath_2_0_1_Foundryпока ваша библиотека ищет Imath_2_1 Пространство имен. Это может указывать на проблему с загрузкой библиотеки (либо из-за того, что она не найдена, либо из-за того, что Nuke не может ее загрузить).

Загрузка библиотеки

Всегда важно помнить, что библиотеки, которые разрешаются ldd не обязательно будут такими же, какие найдет Nuke. Самый простой способ проверить, что на самом деле происходит в Nuke, — это запустить его. strace используя что-то вроде этого:

$ strace -fqo /var/tmp/nuke_strace_output.txt Nuke

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

Запустив пустой сеанс Nuke, попробуйте создать экземпляр своего узла и выйти из Nuke. Теперь вы можете grep через nuke_strace_output.txt и найдите точку загрузки вашего плагина, которая должна выглядеть примерно так:

open("/path/to/MyPlugin.so", O_RDONLY|O_CLOEXEC) = 50

После этого, если вы прокрутите strace В результате вы увидите, какие шаги предпринимает Nuke при попытке загрузить библиотеки, от которых зависит ваш плагин (какие имена он пытается найти, где он ищет и т. д.), которые должны включать libImath (и я догадываюсь libfftw3f).

Двоичная совместимость

Если возможно, я бы порекомендовал попробовать использовать ту же версию OpenEXR, с которой поставляется Nuke, так что вы можете просто воспользоваться ее библиотеками. Вам нужно будет получить свои собственные заголовки, чтобы скомпилировать свой плагин, но это тривиально для чего-то вроде Imath.

Что касается компиляторов, вы должны использовать GCC 4.1.2. Если вы этого не сделаете, то, скорее всего, в какой-то момент вы столкнетесь с проблемами двоичной совместимости.

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

1

Другие решения


По вопросам рекламы [email protected]