Mercury13

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


А что надо — вытащить из MinGW ODBC для Windows (c:\msys64\mingw32\i686-w64-mingw32\include\) и подкорректировать #include, чтобы брало из текущего каталога, а не из стандартного.

// SqlUnglitch.h
#ifdef _WIN32
  #include "SqlWin/sql.h"
  #include "SqlWin/sqlext.h"
#else
  #include <sql.h>
  #include <sqlext.h>
#endif

Причина: в MSYS появилась своя библиотека ODBC с блэкджеком и шлюхами. Под Win64 по соглашениям вызова совпало, а под Win32 — нет. Почему-то при -O0 как-то работает, а уже при -O1 — уже нет.

В 2021 используйте LLD.

К сожалению, я прошу невозможное. И связано это с архитектурой оптимизации при линковке GCC. Дело в том, что сам LD вызывает оптимизатор, и очень, блин, жаль. Ведь у LLVM другое устройство виртуальной машины, которая делает оптимизацию при линковке.

Сейчас куда лучше для отладки использовать линкер LLD. Он В ДЕСЯТКИ раз быстрее, чем LD.
Разумеется, настройки компиляции надо ставить в «самое отлаживаемое» -O0.
Я так и не понял, как ставить иконку и что с LTO — потому выпуск идёт всё ещё через LD.

UPD 2022. А сейчас LD достаточно крут и ничего не нужно!

-fno-tree-* (в общем, все, начинающиеся на tree и входящие в O1).
Дальше выделять бессмысленно, каждая из них делает что-то маленькое.

Но не включаем -fno-tree-copy-prop, оно выводит адову кучу ложных тревог.

UPD. В настоящее время лучше использовать линкер LLD, и точка. Проект разросся, а линковка длится «целых» ДВЕ секунды.

Вот и положите этот libmingwex-0.dll в каталог с программой. Всё в порядке, программа скомпилировалась, остаётся пустить.
Если такое случается при запуске компилятора — что-то с компилятором, и переустановить надо ЕГО.
(Покопался по интернету, завтра проверю на работе свежие версии MinGW)

Например, можно скомпилировать прямо через Qt Creator.

Опять приходится отвечать самому. У меня три ошибки.
Раз.

//#define ZIP_EXTERN __declspec(dllimport)
#define ZIP_EXTERN

Очевидно, libzip рассчитана только на компиляцию в DLL, и точка.

Два. -lz. Ну, это понятно, и эта библиотека в нашем дистрибутиве MinGW есть.

Три — не до конца дописал Юникод.

3) Использование инициализации списком для структур (POD) с уже прединициализированными полями:

Это C++11. Хорошее дело. MinGW поддерживал, пока стандарт ещё вырабатывался. MSVC начал было, да бросил и довёл до конца аж в 2015!!

1) Разное содержимое одних и тех же хедеров

Не выбивается из стандарта.

2) MSVC спокойно компилирует нечто вроде

MSVC ошибается, таким образом неконстантную ссылку передавать запрещено.

но при этом не компилирует код, если не-void функция не возвращает значение

Хорошая диагностика, но это лишь warning, а не error. Компилятору трудно знать, возможен ли тот или иной путь исполнения кода.

Задача lib — указать если не код функций, то хотя бы каким образом их прилинковывать из DLL. В частности, как «искозявлено» имя функции при переводе с Си на Си++. Этот самый lib — издержка разделения функций между компилятором и линкером.
Не знаю, как MSVS/cl, но MinGW/ld с определённого момента начал прилинковывать DLL просто по наличию этого DLL, без построения *.a (а Embarcadero/ilink32, насколько мне известно, умел это изначально). С одной стороны, это серьёзно упрощает жизнь. С другой — для некоторых хитрых способов преобразования имён (или даже без имён, как в небезызвестном storm.dll) он не выцепит, что с чем слинковывать, *.a всё равно потребуется.
stackoverflow.com/questions/31708832/how-to-refere...
www.codeproject.com/Questions/613668/Is-it-possibl...
Простейший, действующий на любом компиляторе способ — это сделать DLL-заглушку со всеми нужными нам функциями в нужных нам соглашениях вызова и с нужным образом закозявленными именами. Код может быть любым, хоть пустым. Компилируем, подставляем этот lib и правильный DLL.
Второй способ — получить список имён функций, собрать их в *.def с правильными соответствиями «имя в коде — имя в DLL» и сделать из этого *.lib. Какими программами это делается в MSVS — описано по одной из ссылок.

Нашёл.
Подключить статический libc++ (-static-libstdc++), тогда всё будет.