LINUX.ORG.RU

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

 


0

3

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

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

Но смысл такой дебажной сборки?

Такой же как и в онтопике - дебажить только свой код

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

«Дебажность сборки» (секрет!) везде этим определяется. В glibc можно нарулить некторые отладочные вещи (например, дополнительною проверку корректности работы с памятью) через переменные среды, а у мелгомягких это разделено на разные рантаймы

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

Да, чего то я не подумал. Странно, что так никто не делает в мс мире (по крайней мере - мне не попадались такие поставки).

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

А что есть управление? Там до 32х текстур *4 флоата (1, 2х или 3х мерных) на входе и столько же на выходе вроде (на самом деле меньше, зависит от реализации) и сколько угодно проходов скольких угодно шейдеров. Любые расчёты от одномерных до сколько угодно-мерных (2х-мерными слоями). Это не так мало...

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

Да я хз куда и как писать. Тем более он мог падать из-за общей... корявости установки. У меня не только инсталл падал, там и при сборке пришлось тесты и ещё какую-то хрень отключить, т.к. они не собирались. Плюс cmake хотел что-то из сети докачать, а у меня на той машине сети нет :)

В общем фиг знает, чем на самом деле вызваны все эти проблемы.

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

В glibc можно нарулить некторые отладочные вещи (например, дополнительною проверку корректности работы с памятью) через переменные среды,

А можно подробнее? А то у меня были траблы с работой с памятью в очень большом проекте. В итоге залепил обёртку на malloc и писал в лог всю работу с памятью. Тормозно, но помогает. из 50..100Мб файла скриптом можно проследить всю историю каждого кусочка (и его соседей, что полезно при вылете за границу выделенной области)

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

Я имел в виду MALLOC_CHECK_, см https://www.gnu.org/software/libc/manual/html_node/Memory-Allocation-Tunables.... Еще MALLOC_TRACE есть, и наверное еще куча вещей которые на вскидку не помню

В итоге залепил обёртку на malloc и писал в лог всю работу с памятью. Тормозно, но помогает. из 50..100Мб файла скриптом можно проследить всю историю каждого кусочка (и его соседей, что полезно при вылете за границу выделенной области)

Похоже на MALLOC_TRACE. Хотя, познакомившись с lttng-ust, я вряд ли когда-нибудь уже буду им пользоваться :)

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

Угу, почти то же самое. Но не учитывает жизнь, только утечку. По полному логи видно, кто поломал память. Обычно если что-то ломается, то виноват тот, кто либо до, либо после этого куска в это же время. Для вынды есть dr-memory или как-то так( который такое палит), но он невероятно тормозной и на больших программах просто не дождёшься утечки.

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

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

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

Тогда да. Ну оверхед да, но по факту это не прооблема обычно. Т.к. нужно редко. Постоянно гонять с этим смысла нет. А если есть - то там уже проще переписать под ноль :) lttng только под лин, как я понял. И требует правки сырцов, что крайне неудобно.

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

Т.к. нужно редко.

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

И требует правки сырцов, что крайне неудобно.

Готовые наборы трейспойнтов не требуют правки сорсов, они грузятся LD_PRELOAD и заворачивают библиотечные функции

annulen ★★★★★
()

Похоже, ты делаешь что-то не так. Я год назад с помощью cmake собирал opencv 2.4 и 3, все собиралось без проблем. mingw был в том числе из qt.

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