LINUX.ORG.RU

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

 


0

3

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

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

Leptonica вообще через задницу написана! Там элементарная операция поиска 4- и 8-связных областей так забыдлокожена, что раз в 10 больше тупит самой элементарной реализации!

Я ее когда-то для морфологических операций использовал, но потом как-то раз, сидя 10 часов в аэропорту (когда надолго задержали рейс), все нужные мне функции написал. Сверил быстродействие и понял, что лептоника — говно!

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

Стандарты видимо разные...

Ты свой проект с >=11 стандартом собираешь? Ежели так, то opencv собирается со стандартом по умолчанию для компилятора, т.е. это скорее всего 03.

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

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

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

А чего же тогда бинарники кутишных семплов под mingw не пускаются с дебажными версиями либ?

Потому что релизные и дебажные dll в Qt называются по-разному, у дежбажных есть суффикс «d». Если собрать дебажную dll с правильным именем, или линковать дебажную сборку с релизной dll, проблем быть не должно, так как нет раздельных «MD» и «MDd»

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

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

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

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

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

Я уже дохрена всего нагуглил, толку только.. Мне гиморно логи тащить, сборка на другой машине без сети. Ну ок, пожалуйста:

mingw32-g++.exe -LD:\optical\cv\lib -LD:\optical\cv\bin -o bin\Debug\test1.exe obj\Debug\main.o -m32 -demangle -m32 -lopencv_imgproc340.dll -lopencv_core340.dll -lopencv_highgui340.dll -lopencv_imgcodecs340.dll
obj\Debug\main.o: In function `main':
D:/optical/cv-test/test1/main.cpp:27: undefined reference to `cv::imread(std::string const&, int)'
D:/optical/cv-test/test1/main.cpp:30: undefined reference to `cv::namedWindow(std::string const&, int)'
D:/optical/cv-test/test1/main.cpp:31: undefined reference to `cv::imshow(std::string const&, cv::_InputArray const&)'
collect2.exe: error: ld returned 1 exit status

Такое сообщение с кривообъявленной ф()

D:\optical\cv-test\test1\main.cpp:15:35: error: 'const' qualifiers cannot be applied to 'cv::String& {aka std::basic_string<char>&}'

Вообще я ещё нагуглил, что basic_string это шаблон, на выходе которого может быть как вариант и string (если я правильно понял) а так же wchar, char16 or char32 string Но если так - почему он тут его подставил в чистом виде?

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

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

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

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

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

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

Кстати с msvc тоже можно линковать релизные dll с дебажными сборками. А вот все объектники и статические либы должны быть собраны с одним рантаймом, либо MD либо MDd

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

кое-какие вычисления вполне можно на шейдерах делать. В OpenGL например

Любые шейдеры это и есть вычисления на GPU, что в программе напишешь, то она считать и будет. Но все типы кроме compute shader являются частью графического пайплайна, в котором не все стадии можно программировать, а compute shader просто запускается и считает

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

Любые шейдеры это и есть вычисления на GPU, что в программе напишешь, то она считать и будет.

Это как-то расходится с моими словами? Просто вариант обойтись без openCL. Без драйверов, увы, не обойтись.

Стадии не нужно программироватью На шейдерах втупую вполне можно считать на фрагментных. Одна/несколько текстур на входе, одна/несколько текстур на выходе. Некоторые вещи вполне неплохо считает. Правда иногда требуется алгоритм немного вывернуть, чтобы адаптировать под такой формат.

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

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

Это как некоторые наркоманы мне тут советовали в OpenGL для элементарных вещей вместо GLUT использовать шейдеры. Упоротые товарищи...

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

Эмм... А вместо чего в глют можно шейдеры? Glut - это обёртка над окошками (кривая довольно). Ну простые фигуры и текст выводить ещё умеет. Собсно больше там ничего нет.

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

Дык, мне opengl нужен лишь для того, чтобы картинку показать (статика или видео), крестики там нарисовать, да график какой. Тут шейдеры не нужны. В дальнейшем, возможно, придется еще GUI делать — кнопочки всякие добавить...

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

Тогда да, глюта достаточно. Но рекомендую glfw. Те же яйца, только в профиль. Но сильно лучше. Перешел на него когда глют окончательно задолбал и вполне доволен. С ним отлично стыкуется imgui - кнопочки в всякое прочее.

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

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

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

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

Как то у тебя линкер перестарался с демэнглингом :)

Пока у меня что-то нет больше идей в чём может быть дело.

Попробуй, сделать таки хеллоуворлд на cmake + findopencv.

Ещё - попробуй полные абсолютные пути до либ прописать, хотя это врят ли поможет...

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

Как то у тебя линкер перестарался с демэнглингом :)

В смысле? На самом деле этот ключ (я писал уже) ни на что не влияет. Просто удалить его забыл.

Пути точно не помогут. Проблема не во время сборки. Проблема ДО сборки. Пока компилятор не будет генерить одинаковые сигнатуры - хрен оно соберётся.

Похоже, что std::string по разному разворачивается, хотя не могу понять как и почему.

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

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

mingw32-g++.exe -LD:\optical\cv\lib -LD:\optical\cv\bin -o bin\Debug\test1.exe obj\Debug\main.o -m32 -demangle -m32 -( -lopencv_imgproc340.dll -lopencv_core340.dll -lopencv_highgui340.dll -lopencv_imgcodecs340.dll -)

или так:

mingw32-g++.exe -LD:\optical\cv\lib -LD:\optical\cv\bin -o bin\Debug\test1.exe obj\Debug\main.o -m32 -demangle -m32 -\( -lopencv_imgproc340.dll -lopencv_core340.dll -lopencv_highgui340.dll -lopencv_imgcodecs340.dll -\)
pon4ik ★★★★★ ()
Ответ на: комментарий от TripleGluk

А с чего ты вообще взял, что cv::String == std::string?

Очень похоже на то, что у них есть своя реализация, совместимая с std::string, и при каких то условиях возможно используется std::string вместо их реализации.

Вот неплохой сайтец: https://demangler.com/

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

А с чего ты вообще взял, что cv::String == std::string?

Так у меня же его хедеры в проекте.

Блин, Действительно внутри есть другая реализация. А как он их тогда вообще сможет совместить, если это разные классы???

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

Не знаю, какой версии у тебя хидеры в проекте, но в актуальной версии нет тайпдефа ни одного который обьявлял бы std::string как cv::String

А если ты использовал какие то другие хидеры, а не те, которые поставляются с либой, то больше никогда так не делай...

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

1. Похоже я в своих мучениях по сборке в 3.4 засунул хедеры от 2.4. 2. В хедерах от 3.4 (публичных, как я понял, которые в include) String вообще нет. Ну хоть что-то понятно стало, спасибо.

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

Или нет. make install копирует из сырцов другие, они не полные. Сам install падает т.к. ему тоже одного хедера не хватает. Почему при сборке всего хватало - хз. Похоже он должен догенерить часть хедеров.

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

на CUDA раз-два и готово, а на OpenCL гемор сплошной.

ну так если на проце общего назначения делать то, к чему он по дизайну не приспособлен, то понятно, что будет медленно.

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

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

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

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

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

Можно на shadertoy.com глянуть примеры всяческих симуляций, вроде Навье-Стокса и т.д. которые хорошо на сетку ложатся.

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

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

Iron_Bug ★★★★ ()