LINUX.ORG.RU

Раздвоение личности std::string под minGW (сборка openCV)

 


0

3

Собственно openCV в итоге собрать удалось, но вот дальше началось непонятное. При сборке тестового проекта (стандартная шняга с открытием картинки) вылетает куча undefined reference. Опытным путём было обнаружено, что у всех функций, которые параметром имеют std::string (алиас cv::String) не совпадает сигнатура и линкёр их не видит. Поиск навёл на подобную проблему со сборкой под мак clang-ом. Там, вроде как, 2 версии разных библиотек с реализацийе std::*, причём сигнатуры как раз совпадают с моими. Вот только никакой информации о подобном раздвоении у minGW не нашлось. При сборке openCV, вроде, никаких подозрительных флагов не нашел и почему такая разница - непонятно. Может кто в курсе, где копать?

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

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

TripleGluk ()

стандартный MinGW раньше вообще не умел в unicode. был отдельный пропатченный MinGW-w64, который в юникод умел. может, ты на эти старые грабли наступил? правда, это было давно. но мало ли. может, они так и не запилили поддержку.

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

через флаг компилятора -D, вестимо.

но это моё предположение. флаг может быть другой. он может требоваться самой библиотеке. надо смотреть хэдеры.

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

Так я изначально писал, что проблема была у тех, у кого их две. Но вот про mingw как раз информации на эту тему нет. Как определить, что их две и какая именно используется? Не понимаю, почему расхождения под одинм компилятором.

С 64 как-то пробовал работать пару лет назад (надо было 64 что-то собрать) - что-то там не зашло. Так на 32 и сижу.

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

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

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

Я сам писал.

Знакомый вообще нафигачил такое, что целый спектрограф трассирует! И модель практически 1-в-1 реальное железо повторяет!!!

А OpenCV — говно. Это как абдурина, только та для далеких от электроники, а эта для далеких от нормальных численных методов.

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

Та у меня тож один такой есть. Фотоны считает. Можно подумать так мало людей, далёких от численных методов. Не нужно путать рабочий девайс и прототип. Одно дело нужен софт/железо для использования в продакшене, а другое - мне вот прямо сейчас нужно запилить прототип, для проверки идеи, при этом никаких наработок в этой области нет. Для второго и на констркторе лего с моторчиками запилить не грех если оно заработает.

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

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

а делать повторение осцилла 1-в-1 в софте - вот это точно наркомания.

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

так это одно и то же, только в профиль. железо-то других функций не имеет.

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

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

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

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

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

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

всё это заточено именно на параллельность и GPU. можно GPU не юзать. будет медленно и печально.

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

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

Но opencv собирался через cmake со всеми настройками, которые там были. Я пытался разобраться, что там происходит, но мало что понял. Никогда с ним сам не работал. Ничего особенного вроде указания конкретной библиотеки или специфичных дефайнов не заметил, но мог и пропустить что-нибудь.

TripleGluk ()

Я не очень помню чё там как под виндой, но, вроде бы бинари собранные с дебажным рантаймом и с релизным не совместимы. Так же как и бинари собранные со статическим и динамическим рантаймом.

О чём линкер может тебе и намекать ;)

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

OpenCV можно юзать и без GPU. Из всего вышесказанного видно, что Вы просто пытаетесь каким-то странным образом оправдать свой фейл. Выше уже на это намекали ни раз. OpenCV - сборник алгоритмов для работы с изображениями. OpenCL - всего лишь один из фреймворков для написания параллельных алгоритмов. Внезапно, OpenCV может собираться с поддержкой OpenCL.

Был бы весь OpenCV про параллельность, все бы алгоритмы параллельные наверное были. Но это не так.

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

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

Что у меня проблема в нём - это понятно. Непонятно - откуда и как она случилась. И что с ней делать.

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

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

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

OpenCV создан специально для GPU? А где это написано, можно ссылочку, пожалуйста?

Есть аналоги OpenCV, которые не заточены под GPU и которые следует выбирать вместо OpenCV, если я планирую запускать их на CPU? Leptonica что ли? Или Leptonica тоже для GPU? Я сейчас говорю про обработку изображений: бинаризации там всякие, Canny и иже с ними.

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

Парадоксально, но факт. При переключении на релиз один из референсов пропал (в смысле - ошибка пропала). Но не все. И сигнатуры пропавшего в либах нет. Та, что есть - с либами как и раньше не совпадает. Скорее всего его оптимизатор просто выпил за ненадобностью.

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

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

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

Ну не абстрактно говори «огромное множество», а назови конкретные либы, которые следует использовать вместо OpenCV, если мне не нужна параллельность и работа на GPU.

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

как математик, открою тебе секрет: любые либы для работы с матрицами. там ничего кроме этого нет.

более того, я это всё в детстве на ассемблере писала. через матрицы. трассировку и прочее. это элементарная математика.

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

Своё - стандартно. Пробовал включать/выключать с11 только и принудительно указывать либу -lstdc++ Сейчас дефолт только: -m32 -g С opencv сложнее. Где там смотреть их? Там cmake что-то химичит по результатам настроек. В гуи видны некоторые очевидные, но там дофига всего, в т.ч. и малопонятного. И как оттуда скопировать неясно. Вроде в makefile ничего особенного не видел.

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

как математик, открою тебе секрет: любые либы для работы с матрицами. там ничего кроме этого нет.

Это логически вытекло из того, что изображения представляются в памяти матрицами что ли? Серьезно?

более того, я это всё в детстве на ассемблере писала. через матрицы. трассировку и прочее. это элементарная математика.

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

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

Генерится файл CMakeCache.txt, в котором будет указано, что ты там поменял в cmake-gui. Также при запуске cmake он в лог пишет, какие опции с какими значениями были выбраны

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

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

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

нет, но это всё далеко не новые и не уникальные алгоритмы. все они давно известны и написаны ещё в 90-х годах. я просто не интересуюсь графикой от слова совсем. но библиотеки такие есть и в изобилии.

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

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

Кстати вышеперечисленное как раз не очень сложно. Только писанины много.

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

так GPU как раз расчитаны на векторные операции и перемножение матриц. там это самая главная задача. это уже потом туда прочую математику попытались засунуть. типа, шейдеров много, можно параллельно что-то вычислять. но изначально весь OpenGL стандарт - это векторы и матрицы, и всё, что с ними связано. ну, там ещё минимальная тригонометрия есть.

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

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

Я выше называл уже Leptonica (и то это немного другое). Ещё?

zamazan4ik ★★ ()