Russian Qt Forum

Сообщество запаздывает с актуальностью сборок mingw, уже зарелизили 4.6.1, а они раздают сборку почти годичной давности.
Для тех кто хочет юзать новых фичи из c++0x, не дожидаясь пока сообщество надумает сделать новую сборку:
Mingw (http://code.google.com/p/mingw-builds/downloads/list)
с полной поддержкой LTO (http://en.wikipedia.org/wiki/Link-time_optimization), OpenMP (http://en.wikipedia.org/wiki/OpenMP), Graphite (http://gcc.gnu.org/wiki/Graphite), std atomics (http://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.4/a01022.html) и std threads (http://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.4/a01000.html)
Планируется добавить в сборки некоторый набор библиотек (ssl, boost, Qt, возможно некоторые другие)

обновлены сборки.
http://code.google.com/p/mingw-builds/downloads/list

на днях рассчитываю зарелизить 4.6.1

зарелизил 4.6.1: http://code.google.com/p/mingw-builds/downloads/detail?name=mingw32-gcc-4.6.1-release-20110830.7z
пора готовиться к 4.6.2

добавлены новые сборки.

добавил новые snapshot сборки.
отныне, все сборки будут включать в себя следующие ЯП: c, c++, objc, obj-c++, fortran.

в планах - разобраться со сборкой java.

вообще, в глобальных планах, создать инсталлятор, в котором юзер сможет выбрать:
1. способ реализации исключений(sjlj/dwarf)
2. версию компилятора.
3. x86/x86_64 как цель, так и хост архитектуры.
4. список необходимых ему предкомпилированных библиотек. (да. юзеру не нужно будет шарахаться по инету в поисках собранной библиотеки, или маять свой моцг в попытках собрать ее)
5. IDE. планирую следующие: QtCreator, NetBeans, Code::Blocks, Dev-C++, wxDev-C++. т.е. получится своего рода portable версия среды разработки со всем перечисленным.

по этому, проект переезжает на sf.net, ибо там нет ограничения на пространство для проекта, плюс, больше возможностей по управлению проектом(в отличии от гуглкода).
сейчас занимаюсь следующими задачами:
1. переписываю скрипты системы сборки.
2. пытаюсь разобраться со сборкой java.
3. пытаюсь разобраться со сборкой под x86 и x86_64 архитектуры. как для хоста, так и для цели.
4. дописываю скрипты для сборки библиотек.
5. разбираюсь с NSIS инсталлятором.

Несколько часов назад состоялся релиз компилятора GCC версии 4.6.2, в котором проведена работа по исправлению ошибок, регрессивных изменений и проблем с совместимостью. С момента выхода прошлой версии отмечено 115 исправлений (http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.6.2), большинство из которых связано с устранением внесенных ранее регрессивных изменений и с улучшением поддержки спецификаций C++0x. Исходные тексты компилятора можно загрузить с сайта проекта (http://ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.6.2/) или с его зеркал (http://gcc.gnu.org/mirrors.html).

Сборки MinGW на базе GCC-4.6.2 вы уже сейчас можете скачать на странице проекта (http://code.google.com/p/mingw-builds/downloads/list).
Следующее обновление GCC 4.6.3 ожидается в феврале.

залил новые сборки тестовой ветки 4.7.0 в которых впервые реализована технология Transactional Memory (http://gcc.gnu.org/wiki/TransactionalMemory)(кстати Intel эту фитчу реализовал довольно давно). полагаю, эта фитча станет невероятно востребована в паре с OpenMP, что позволит сделать мир многопоточных программ проще  :) отдельно хочется поблагодарить Red Hat inc. за "подаренную" реализацию Transactional Memory (http://gcc.gnu.org/wiki/TransactionalMemory), которая, к тому же, всего три месяца назад "подарила" реализацию OpenMP-3.1 (http://www.openmp.org/mp-documents/OpenMP3.1.pdf).

скачать версии GCC для windows вы как всегда можете скачать тут (http://code.google.com/p/mingw-builds/downloads/list). совершенно бесплатно  ;)

занимаюсь сборкой для x86_64 архитектуры, и возникли такие вопросы:
1. нужна ли сборка хост-x86_64 - цель-x86_64 ? или же достаточно будет хост-х86 - цель-х86_64? ибо последняя сможет работать как х86 так и на х86_64.
2. есть ли смысл собирать отдельные сборки для х86 и х86_64 хостов? или же собрать хост-х86 и мультицель х86/х86_64 указываемая при помощи стандартных опций "-m32" "-m64" ?

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

так же, исправил баг LTO в сборках 4.7.0, который не давал мне покоя уже 4 месяца.

выложил snapshot сборки 4.7.0.
готовлюсь к релизу :)

качать тут (http://code.google.com/p/mingw-builds/downloads/list).

не к холивару будет пост, но только что в списке рассылки GCC были опубликованы (http://willus.com/ccomp_benchmark2.shtml?p1) сравнительные результаты тестирования компиляторов проводимые Willus.com.
в тестировании принимали участие компиляторы (http://willus.com/ccomp_benchmark2.shtml?p2): MinGW (gcc 4.6.3), Intel 2011, Microsoft 2010 Visual C/C++ Express, и др.(Tiny CC, Digital Mars, MinGW (gcc 3.4.2)). использовались следующие опции (http://willus.com/ccomp_benchmark2.shtml?p3). тестировались такие проекты (http://willus.com/ccomp_benchmark2.shtml?p4) как: BW1D, BZIP2, CRAFTY, K2PDFOPT, LAME, MESHER, MODEL3D, RESIZER, TRANSCEND, X264. тесты проводились в таком (http://willus.com/ccomp_benchmark2.shtml?p5) окружении:
в пяти из десяти тестов GCC-4.6.3 незначительно отставал от MSVC.
усредненное значение пересчитанное мною таково:
GCC - 15.13
MSVC - 15.12

т.е. MSVC на одну сотую секунды быстрее из суммы всех времен тестов. а Intel рвет всех.

для остальных компиляторов не считал.

Всем привет.

Если вдруг кто не знает, mingw-builds (http://code.google.com/p/mingw-builds/) - это проект предоставляющие сборки компилятора GCC (http://gcc.gnu.org/) для Windows платформы, т.е. MinGW.

Итак...
До сих пор, проект предоставлял сборки с двумя типами реализации исключений: 1)dwarf (http://en.wikipedia.org/wiki/DWARF), 2)sjlj(1 (http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.html), 2 (http://www.on-time.com/ddj0011.htm)).
Сборки использующие dwarf, будут исключены из последующих сборок проекта mingw-builds (http://code.google.com/p/mingw-builds/).
Связанно это с двумя причинами:
1. dwarf, для windows ОС - это инородный способ реализации исключений, он не может работать правильно в windows из-за того, что реализация как С++ так и Си(SEH (http://en.wikipedia.org/wiki/Microsoft-specific_exception_handling_mechanisms#Structured_Exception_Handling))  исключений в компиляторе MSVC использует SJLJ. В связи с этим, возникают трудноуловимые ошибки связанные с разрушением стека и пробросом/ловлей исключений между .dll модулей. Мнение разработчиков CRT для MinGW(mingw-w64) тут (http://sourceforge.net/apps/trac/mingw-w64/wiki/Exception%20Handling).
2. и вторая причина, вытекающая из первой - отсутствие реализации dwarf для windows-x86_64.

Посему, пользователям dwarf сборок придется пересобирать либы. Увы...

С этого момента, проект mingw-builds (http://code.google.com/p/mingw-builds/) предоставляет сборки для двух хостов: a)i686, b)x86_64.
Каждая такая сборка, является двухцелевым кросс-компилятором. Компилятор для i686 хоста по умолчанию собирает для i686 цели. Компилятор для x86_64 хоста по умолчанию собирает для x86_64 цели.

Для того, чтоб при помощи компилятора для i686 хоста собрать для x86_64 - при компиляции и линковке добавляйте флаг -m64.
Для того, чтоб при помощи компилятора для x86_64 хоста собрать для i686 - при компиляции и линковке добавляйте флаг -m32.

Разумеется, все зависимости цели должны быть собраны соответствующим образом.

Теперь о зависимостях цели от .dll модулей поставляемых в составе компилятора(libstdc++-6.dll, etc...).
Как правило, при использовании MinGW, путь к mingw/bin прописывается в PATH. Все необходимые для хоста .dll модули так же находятся в mingw/bin. По этому, проблем с выполнением полученных исполняемых файлов нет. Но при использовании кросс-компилятора все немного сложнее.
Если производится сборка при которой host==target - тут все как обычно, ибо .dll модули находятся в mingw/bin. Однако, в случаях когда host!=target, .dll модули оказываются недоступными для целевого исполняемого файла.
Для i686 компилятора, .dll модули для x86_64 цели располагаются в mingw/i686-w64-mingw32/lib64.
Для x86_64 компилятора, .dll модули для i686 цели располагаются в mingw/x86_64-w64-mingw32/lib32.

Если что не понятно - задавайте вопросы.

Сборка для i686 уже готова. Со сборкой для x86_64 хоста возникли некоторые сложности. На страницу проекта пока не выгружал. Хочу одновременно.

Всем спасибо.

Огромное спасибо за сборки. Чуть ли не каждый час обновляю страницу в надежде увидеть заветное 6.7.0-release  :).

4.7.0)

по идее, сегодня-завтра.

визуализация всего периода разработки GCC: http://www.youtube.com/watch?v=ZEAlhVOZ8qQ

Выгрузил следующие сборки:
1. i686-mingw32-gcc-4.6.3-release-c,c++,fortran-sjlj
2. x86_64-mingw32-gcc-4.6.3-release-c,c++,fortran-sjlj
3. i686-mingw32-gcc-4.7.0-release-c,c++,fortran-sjlj
4. x86_64-mingw32-gcc-4.7.0-release-c,c++,fortran-sjlj

жду отзывов :)

Итак.
В проекте mingw-builds (http://code.google.com/p/mingw-builds/) произошли два изменения:
1. проект переехал на sf.net. тыц (http://sourceforge.net/projects/mingwbuilds/).
2. опубликованы скрипты сборки с помощью которых вы самостоятельно можете собрать MinGW.
Получить вы можете выполнив эту команду:
    git clone git://git.code.sf.net/p/mingwbuilds/code mingw-builds

Архивы с собранным MinGW вы сможете скачать тут (http://sourceforge.net/projects/mingwbuilds/files/).
На данный момент скачивать нечего. Сейчас пересобираю все доступные версии. Сегодня залью.

Так же, для каждого собранного MinGW буду выгружать архивы с исходниками, ибо этого требует лицензия GPL.

Буду признателен если кто-либо попробует воспроизвести процесс сборки на своей машине и в своем окружении.
Инструкция (http://sourceforge.net/p/mingwbuilds/code/ci/72b33e43ffe791e9a3a54722c70193b2f3446f13/tree/README.TXT) по использованию скриптов.

Всем спасибо!

Сегодня состоялся релиз системы сборки MinGW в рамках проекта MinGW-builds под версией 0.1.0.
Из основных изменений произошедших с момента первого коммита, можно отметить следующие:

• Добавлен ключ --preload, заставляющий систему сборки сначала скачать все исходники, и только потом собирать. Необходим для одновременной сборки сразу нескольких версий.
• Добавлен ключ --dwarf, информирующий систему сборки использовать DWARF вместо SJLJ. При этом, доступна сборка только для i686 хоста, и только для i686 цели.
• Для каждой версии GCC, отныне, отдельный конфигурационный файл.
• Аргументы командной строки более не зависят от порядка написания.
• Логи сборки более не вставляются в архив со сборкой.
• С этого момента, архивы со сборками снова содержат суффикс используемой сборкой реализации исключений.
• Msys (https://sourceforge.net/projects/mingwbuilds/files/External%20binary%20packages/), со всеми необходимыми для сборки MinGW тулзами(7z+wget+svn+git+mercurial+cvs), вы теперь можете скачать на странице проекта.
• Добавлен патч исправляющий ошибку (https://sourceforge.net/mailarchive/message.php?msg_id=29215821), возникающую при генерации компилятором кода развертывания стека и использованием GetLastError() (http://msdn.microsoft.com/en-us/library/windows/desktop/ms679360(v=vs.85).aspx) в этом скопе.
• Добавлены следующие тесты: 1)тест POSIX-RT функций, 2)тест С++11 sleep_for/sleep_until функций, 3)тест GetLastError() при развертывании стека.

Инструкцию по использованию системы сборки MinGW-builds вы можете прочесть здесь (http://sourceforge.net/p/mingwbuilds/wiki/Installing%20MinGW-builds/).

Несколько часов назад состоялся релиз компилятора GCC версии 4.7.1.
Это первый баг-фикс релиз для ветки 4.7.х.
Было исправлено 117 багов. Полный список вы можете обозрить тут (http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.7.1&list_id=34041).

Уже сейчас вы можете скачать сборки MinGW на базе GCC-4.7.1 (http://sourceforge.net/projects/mingwbuilds/files/windows-host/4.7.1/release/).

бинарная сборка Qt не поддерживает gcc 4.7, увы.

не та модель исключений?

ничего удивительного.

не та CRT.

Почему так происходит? В gcc 4.6.2 w32api 3.17, и оно тоже ВРОДЕ БЫ КАК несовместимо с бинарной сборкой Qt, но всё работает прекрасно?

во-первых - gcc-4.6.x и gcc-4.7.x - имеют несовместимую ABI.
во-вторых - CRT от mingw-org и mingw-w64 имеют разные кодовые базы, которые они не стараются делать совместимыми, за ненадобностью первого, ибо тупик.

несколько дней назад, я наткнулся на очень необычный баг при использовании кути собранной компилятором использующим mingw-org, и компилятором использующим mingw-w64. проблема была в том, что понепонятным причинам происходил deadlock там, где его в принципе быть немогло. по ходу разбирательства, заметил, что неправильно/не_в_том_порядке деструктятся объекты/мемберы-данные.

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

коварный баг =)

ps
при всем при этом, коллега говорит что такой "комплект" он использует уже несколько месяцев. и никаких багов не замечал =)

пересобрал (http://sourceforge.net/projects/mingwbuilds/files/windows-host/4.7.1/release/) MinGW на базе gcc-4.7.1-release.
обновил GDB до версии 7.4.1, и GNU make с этого момента собирается с поддержкой job-server.(благодарность для Alexpux за патчи и внесение изменений в систему сборки)
для пользователей Qt это станет приятным бонусом, ибо теперь у них появится возможность производить сборку Qt и проектов основанных на .pro файлах в требуемое кол-во потоков.

качать архивы с пометкой 'rev2'.

Сегодня состоялся релиз системы сборки MinGW-builds (https://sourceforge.net/projects/mingwbuilds/) под версией 0.2.0.
В эту версию вошли следующие изменения:

• Добавлен ключ --download, выполняющий только загрузку исходников, без сборки.
• Добавлен ключ --no-multilib, информирующий систему сборки собрать одноцелевой MinGW.
• Добавлен ключ --rev=N, использующийся для указания номера ревизии сборки.
• Добавлен ключ --threads=model, использующийся для указания используемой сборкой модели потоков. Доступны: posix/win32. При использовании win32 модели, функционал из std concurrency (http://en.cppreference.com/w/cpp/thread) окажется недоступным. (требуется WIN-программер способный дореализовать WIN backend (http://gcc.gnu.org/viewcvs/trunk/libgcc/gthr.h?view=markup))
• Добавлен ключ --mingw-compress, использующийся для указания системе сборки сжать собранный MinGW в архив.
• Добавлен ключ --srcs-compress, использующийся для указания системе сборки сжать исходники используемые для сборки MinGW в архив.
• Добавлен патч исправляющий ошибку, возникающую при генерации компилятором кода эпилога развертывания стека и затирающую WIN32 LastError в этом скопе.
• С этого момента, GNU make поставляемый в составе сборок производимых проектом MinGW-builds, собирается с поддержкой job-сервера.
• MSYS доступный для загрузки со страницы проекта MinGW-builds обновлен. Добавлен модуль gettext для M4 макропроцессора. (качать (https://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/) архивы с суффиксом 'rev1')

Благодарность коммитерам и тестерам за внесенные изменений и тесты.

Эта версия системы сборки MinGW-builds является последней и завершенной для нативной сборки в windows. Следующими этапами будет внесение необходимых изменений позволяющих использовать MinGW-builds как для сборки нативного MinGW, так и для сборки кросс-MinGW для Linux и OSX хостов.

немного новостей касательно gcc/MinGW.

недавно, в транк, был влит патч реализующий SEH для Win64: http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00512.html (http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00512.html)
как оказалось, в патенте борланд на SEH нашли лазейку. а именно, то, что патент оговаривает идею SEH для Win32, но не для Win64. в виду этого, было решено принять этот патч в транк, т.к. для Win разработчиков SEH является весьма необходим. но, у этого патча есть и минусы, для меня, по крайней мере. как некоторые могли заметить, я уже больше месяца не произвожу сборки транка. и это "благодаря" этому патчу. но, транк есть транк. он и не должен собираться. надеюсь, к релизу 4.8.0 эту недоразумение пофиксят.

вторая новость состоит в том, что расширение 'Intel Cilk-Plus' принято в транк: http://gcc.gnu.org/ml/gcc/2012-08/msg00355.html (http://gcc.gnu.org/ml/gcc/2012-08/msg00355.html)
это означает, что gcc, начиная с версии 4.8.0 будет поддерживать 'Cilk-Plus'. тот, кто знаком с этим расширением при использовании Intel компилятора, понимает, насколько это расширение необходимо для разработчиков многопоточных алгоритмов/программ.

третья новость состоит в том, что разрабы Qt пытаются определится в выборе MinGW (http://qt-project.org/wiki/MinGW-64-bit) для распространения в составе QtSDK-64bit. и я горд сообщить о том, что кандидатов всего двое: 1)сборки проекта MinGW-builds, 2)mingw-w64 персональная сборка Ruben`а. есть надежда, что сборки проекта MinGW-builds выйдут в массы :yahoo

Такой вопрос... Есть ли смысл использовать данную сборку для обычной GUI программы, в которой нет ни вычислений ни сложной графики? Сейчас я использую стандартный mingw с gcc-4.6.2. Пока заметил, что после сборки компилятором i686-mingw32-gcc-4.6.3 размер Qt библиотек заметно вырос - около 1.5Мб суммарно на Gui+Core+Network+Sql. Тестировал также скорость загрузки программы - никакой разницы не заметил.

какую конкретно?

я, право, уже и не знаю как реагировать на подобные посты %)
ладно, когда вопрос стоИт в том, использовать Qt или wx - то в этом случае критерий типа "размер" - имеет вес. но при использовании такого монстра как Qt, экономить полтора метра - имхо, что-то с логикой не так %)
почему размер больше? - банально, из-за более агрессивной оптимизации. о чем собственно пишут в релизнотс к каждому выпуску компилятора.

мне он не подходит. в нем куча багов и недоделок. даже в 4.7.0 их хватало. даже в 4.7.0 были недоделки которые не позволяли мне реализовать некоторые задачи. только 4.7.1 позволил почувствовать мощь С++11.
конечно, инструмент выбирается по задаче, раз уж вам 4.6.2 хватает.

этим вы скорее тестировали скорость вашего харда, ибо динамический резолв символов в dll`ках таких размеров - та еще волокита %)


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


[офтопик]
кстати, несколько часов назад, тролли обновили страничку тестирования: http://qt-project.org/wiki/MinGW-64-bit
MinGW-builds впереди.
[/офтопик]

i686-mingw32-gcc-4.6.3


Всё так, я компилирую Qt сам, и уже снизил его размер в два раза. Gui модуль похудел до 5300 Kb. При использовании mingw-builds он потолстел до 6000 Kb - более чем 10%, ощутимо.

Ещё один вопрос - в стандартном mingw есть рантайм в виде всем известных mingwm10.dll и libgcc-*.dll. В mingw-builds его нет, почему? Не вкомпиливается ли он случайно в каждый бинарник?


Вопрос как раз в том, даст ли это что-то для обычной GUI программы. Без тяжёлой графики или вычислений.


Разве внешние символы не резолвятся все сразу лоадером при запуске?


Они смотрят в сторону x86_64, что, опять же, для меня неважно - я делаю 686 билд.

Я желаю проекту победить и все дела, но я хочу иметь конкретную информацию, может и мне стоит перейти на mingw-builds даже несмотря на  увеличение размера бинарника.

тут две причины:
1. MinGW-builds использует другe. CRT.
2. MinGW-builds правильно конфигурирован.

нет.

нет.
разве что, в 4.7.1 корректно работают модули std_concurrency и chrono. (не без моей помощи. хотя, еще один баг присутствует в chrono. никак не доберусь до него)
и если предполагается саморазвитие, то это не лишне.

при загрузке системы? - нет. а раз нет - они резолвятся при загрузке dll`ки.

кстати да, изменить тулчейн для i686 они не могут из-за того, что CRT используемая в их текущем тулчейне(4.4.1 ?), бинарно несовместима с CRT используемой в MinGW-builds. т.е. при изменении тулчейна к примеру на MinGW-builds i686, всем пользователям придется пересобирать dll`ки, а это гиморно %) их просто проклянут за это =)

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

при загрузке программы

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

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

В проекте MinGW-builds произошло несколько изменений.

1) Проект изменил свое отношение касательно производимых сборок. Так, до сегодняшнего дня, проект MinGW-builds производил сборки только с использованием 'threads=posix', и не производил сборки использующие DWARF.
Впредь, проект MinGW-builds будет производить сборки с использованием 'threads=posix' и 'threads=win32', а так же и с использованием как SJLJ так и DWARF и SEH(только для 4.8.0 и выше, и только для хоста x86_64)
К примеру, для GCC-4.7.2-release, будут доступны следующие сборки:
 - x32-4.7.2-release-posix-sjlj
 - x32-4.7.2-release-posix-dwarf
 - x32-4.7.2-release-win32-sjlj
 - x32-4.7.2-release-win32-dwarf
 - x64-4.7.2-release-posix-sjlj
 - x64-4.7.2-release-win32-sjlj
Скриншот (http://clip2net.com/clip/m47996/thumb640/1349433339-clip-14kb.png) поясняющий назначение каждой составляющей в имени сборки.

2) Проект изменил структуру каталогов. Скриншот (http://clip2net.com/clip/m47996/thumb640/1349540175-fs-tree-description-23kb.png) поясняющий новую структуру каталогов.
3) Все сборки будут выгружаться только в виде .7z архивов.
4) Тестовые сборки(prerelease/snapshot) будут собираться минимум раз в месяц. Возможно чаще, но не реже.
5) Из поддерживаемых сборками ЯП удален фортран.

На данный момент доступны следующие сборки:
 - 4.6.2
 - 4.6.3
 - 4.7.0
 - 4.7.1
 - 4.7.2

Все сборки были пересобраны с использованием последних доступных версий gmp/mpfr/mpc/ppl/cloog/mingw-w64-headers/mingw-w64-crt/gdb.

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

Со следующих билдов mingw-builds будет поставляться с полноценным Python-2.7.3, который будет собираться из исходников вместе со сборкой, в поддиректории "opt". С этим Python будет линковаться gdb.
На данный момент код для сборки Python из исходников с помощью mingw добавлен в репозиторий. Существует несколько проблем после решения которых все сборки будут комплектоваться Python собственной сборки.

как и обещалось ранее, проблемы со сборкой пайтона решены(благодаря Алексу).

были пересобраны все сборки версии 4.7.2 с суффиксом 'rev1', в связи с двумя(1 (https://github.com/niXman/mingw-builds/blob/master/patches/make-linebuf-mingw.patch), 2 (https://github.com/niXman/mingw-builds/blob/master/patches/make-remove-double-quote.patch)) добавленными патчами для make, и в связи с появлением в проекте пайтона собственной сборки.

думаю, через несколько недель тестов, будет релиз 0.4.0.

Скажите пожалуйста: при сборке чего-либо (например Qt в qmake.conf переменная QMAKE_{CXX,L}FLAGS_EXCEPTIONS_ON) какой из флагов -mthreads / -pthread необходимо указывать для каждой сборки (или любой флаг для каждой?)? Также интересует вопрос, нужно ли указывать библиотеки -lgomp -lpthread явно для опции -fopenmp (и работает ли она вообще в вашей сборке?) в случае, когда необходимо указывать -mthreads? Будет ли работать для ваших сборок -D_GLIBCXX_PARALLEL?

достаточно указать '-pthread'

нет. все необходимые флаги и библиотеки, устанавливаются/подключаются автоматом.

вы о параллельных алгоритмах? если "да" - то они работали. (кстати, добавляю в сборки тест для проверки параллельных алгоритмов, а то что-то я совсем забыл про них)

Просмотрите пожалуйста эту (http://www.prog.org.ru/topic_23706_0.html) тему.

вчера, разработчики Qt приняли решение относительно официального MinGW, используемого для сборки QtSDK, и поставляемого в составе QtSDK.
и все же, их выбор пал на MinGW-builds (http://lists.qt-project.org/pipermail/development/2013-January/009415.html), чему я несказанно рад! это наша(проекта MinGW-builds) маленькая победа, надеюсь что не последняя :yes3

хочу выразить благодарность от лица авторов проекта(я и Alexpux (https://github.com/Alexpux)) всем пользователям наших сборок, за баг-репорты, рекомендации, и просто за фид-бэк.
спасибо вам!

И вам спасибо. Извините, конечно, за мой фидбэк.

Не известно еще когда ожидать официальной сборки Qt5 на mingw?

нет. по пока что, глянь в конце страницы:
http://qt-project.org/wiki/MinGW-64-bit

или взять предкомпилированное здесь:
http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/Qt-Builds/

Как раз этим и пользуюсь, спасибо. Просто интересно было когда тролли соберут.

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

Здравствуйте. Я скачал вашу сборку Qt 5.0.1 x64 (sourceforge.net/projects/mingwbuilds/files/external-binary-packages/Qt-Builds/), но у меня возникли проблемы при сборке моего проекта. На самом деле проблемы возникли раньше, при запуске QT Creator, но знающий человек помог решить проблему.
И так, начну сначала:

1) Скачал Qt 5.0.1 x64 (sourceforge.net/projects/mingwbuilds/files/external-binary-packages/Qt-Builds/).

2) Скачал MinGW (sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.7.2/64-bit/threads-posix/sjlj/), так как в дальнейшем он понадобиться.

3) Положил Qt в C:\Qt\Qt64-5.0.1, так же в эту папку положил папку mingw (из скаченного MinGW).
(http://s2.ipicture.ru/uploads/20130211/thumbs/ouxVjP96.png) (http://s2.ipicture.ru/Gallery/Viewfull/21599173.html)

4) Правил файл C:\Qt\Qt64-5.0.1\bin\qt.conf, а именно его содержимое стало
5) Прописал (дописал) в PATH
(http://s2.ipicture.ru/uploads/20130211/thumbs/L8wpa43U.png) (http://s2.ipicture.ru/Gallery/Viewfull/21599174.html)

6) Настройки QT выглядеть стали так:
(http://s2.ipicture.ru/uploads/20130211/thumbs/UVdW0t2Q.png) (http://s2.ipicture.ru/Gallery/Viewfull/21599175.html)
(http://s2.ipicture.ru/uploads/20130211/thumbs/PDXCA85r.png) (http://s2.ipicture.ru/Gallery/Viewfull/21599176.html)
(http://s2.ipicture.ru/uploads/20130211/thumbs/DmEGU0Lg.png) (http://s2.ipicture.ru/Gallery/Viewfull/21599177.html)
(http://s2.ipicture.ru/uploads/20130211/thumbs/yi3cWA7m.png) (http://s2.ipicture.ru/Gallery/Viewfull/21599178.html)
(http://s2.ipicture.ru/uploads/20130211/thumbs/PapRjFOS.png) (http://s2.ipicture.ru/Gallery/Viewfull/21599179.html)

7) Создаю новый проект и пытаюсь запустить, но вылетает ошибка:
(http://s2.ipicture.ru/uploads/20130211/thumbs/WW351Upa.png) (http://s2.ipicture.ru/Gallery/Viewfull/21599180.html)
(http://s2.ipicture.ru/uploads/20130211/thumbs/hppAT54a.png) (http://s2.ipicture.ru/Gallery/Viewfull/21599181.html)

Пожалуйста объясните в чем дело (чем подробнее тем лучше)?  ???

давай разделим на два отдельных вопроса.
1) проблема с компилятором?
2) проблема с Qt?

пока что по первому вопросу:
создай не-Qt проект. простой плюсовый проект с хеловордом:

C++ (Qt)
#include <iostream>
int main() {std::cout << "Hello, World!" << std::endl;}
 

скомпиль и выполни его, и отпишись о результате.

так же, сообщи номер билда ОСи(win7, насколько я понял? x86_64?)
в system32 отыщи dll`ку msvcrt.dll, и покажи информацию о ней.
и в добавок, покажи список импорта полученной exe`шки хеловорда.

Программку на С++ создал, все прошло успешно:
(http://s2.ipicture.ru/uploads/20130212/thumbs/274wWQWQ.png) (http://s2.ipicture.ru/Gallery/Viewfull/21601230.html)

ОС Вин7 х64:
(http://s2.ipicture.ru/uploads/20130212/thumbs/3ryrueRK.png) (http://s2.ipicture.ru/Gallery/Viewfull/21601231.html)

Информация о msvcrt.dll:
(http://s2.ipicture.ru/uploads/20130212/thumbs/2Z7V12Jd.png) (http://s2.ipicture.ru/Gallery/Viewfull/21601232.html)

А вот с проектом беда:
(http://s2.ipicture.ru/uploads/20130212/thumbs/YTqDyw7H.png) (http://s2.ipicture.ru/Gallery/Viewfull/21601233.html)

Вот что по этому поводу говорят разработчики Qt:
"qt.conf is picked up from the directory of the current binary. So to make it work you'd have to put a qt.conf also in the bin folder of your example application ... There's unfortunately no 'global' place to put a qt.conf in, you'll have to patch the paths in e.g. Qt5Core.dll to match the local installation path if you want to have it transparent."

По-русски это значит что ты должен ложить qt.conf в папку с бинарником твоей проги. Это нужно только для запуска из под QtCreator.

Спасибо!

Здравствуйте!
У меня по упомянутой выше теме вопрос.
Есть пакет приложений, которые написаны с помощью Qt. После перехода на Qt5 встал вопрос об инсталляторе (о том, что изменился набор бибилиотек, которые необходимо таскать и что это все теперь весит очень много, написано достаточно, но речь не об этом). В моем случае все библиотеки устанавливаются в одном место и все приложения их используют. Но в библиотеке Qt5Core.dll жестко зашиты пути к плагинам (а теперь, как я понял, нужно помимо прочего устанавливать библиотеку plugins\platforms\qwindows.dll). Таким образом, прописав пути к библиотекам в PATH, я не могу запустить приложения, поскольку при загрузке Qt5Core.dll ищется qwindows.dll по зашитому пути.
Пока единственный рабочий вариант (упомянут выше) - положить qt.conf в папку каждого приложения с прописанным prefix. Но это кажется несколько странным, тем более если приложений много.

В Hex редакторе в Qt5Core.dll я нашел места, где прописаны пути. Но ручная правка не дает результата - нарушается целостность библиотеки.
Эти пути прописываются корректно при установке QtSDK (написано в этой теме http://qt-project.org/forums/viewthread/23931). Но пока разбираться, как это делается в QtSDK, я не стал.
Может быть, кто-то подскажет, как быть в такой ситуации?

P.S. По теме - спасибо за сборки mingw. Все работает:собирал Qt с помощью mingw (32 и 64) на потоках win32.

Если собираетесь патчить dll то вам необходимо взять патчер из инсталлятора или выдрать его из исходников исталлятора и собрать себе мини патчер)
Вообще очень странно что готовая программа требует qt.conf или иных извращений. На днях попробую собрать какую-нибудь простенькую прогу и посмотрю что можно сделать.
По моему мнению qt.conf нужен только для того чтобы можно было корректно пользоваться qmake и другими утилитами разработчика.

и еще для плагинов.

Покрайней мере в Qt4 ничего не нужно было чтобы программа работала...

О чем и речь. Странно, что все так складывается в новой версии. Может быть, разработчики Qt предложат другие варианты.
Патчить, конечно, не хотелось бы. Но тут сложно сказать, что менее эстетично: класть в каждую папку приложения один и тот же файл или курочить готовую библиотеку (что кстати должен делать инсталлятор).

Каким образом ты кладешь плагины в папку с программой? Опиши структуру получаемой директории

QApplication::addLibraryPath() не?

а я хз, я кутю не использую.

После установки пакета программ получается следующая структура:
INSTALL_DIR
 +APP1
 +APP2
 +APP3
 +lib
   +plugins
     +platforms
        qwindows.dll
   Qt5Core.dll
   Qt5Gui.dll
   ....

Путь INSTALL_DIR/lib добавлен в %PATH%. Без файла qt.conf (в каждой папке приложения), в котором в prefix указано INSTALL_DIR/lib, приложения не запускаются.

Я пробовал по аналогии с тем, как это есть при установке Qt сами библиотеки (Qt5Core.dll и т.д.) положить в подпапку bin (INSTALL_DIR/lib/bin), но это ни к чему не привело. Пробовал qwindows.dll положить рядом с Qt5Core.dll - не помогает.

Попробуй вынести все содержимое папки plugins в корень, т.е.:

INSTALL_DIR
 +APP1
 +APP2
 +APP3
 +lib
     +platforms
          qwindows.dll
     Qt5Core.dll
     Qt5Gui.dll
   ....

Не помогло.
Вообще в документации есть статья на эту тему (http://qt-project.org/doc/qt-5.0/qtdoc/deployment-windows.html)
И все 3 пути указаны (QApplication::addLibraryPath() - указан 2-м).


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

вчера состоялся релиз gcc-4.8.0.
уже сейчас вы можете скачать сборки MinGW на базе gcc-4.8.0 со страницы проекта (http://sourceforge.net/projects/mingwbuilds/).
в 4.8.0 для windows платформы, появилась возможность использовать SEH(1 (http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.0/64-bit/threads-win32/seh/x64-4.8.0-release-win32-seh-rev0.7z), 2 (http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.0/64-bit/threads-posix/seh/x64-4.8.0-release-posix-seh-rev0.7z)). но, из-за патентных ограничений, эта возможность доступна только в x86_64 сборках.

И из папки lib на уровень к APP1

вчера состоялся релиз GCC за версией 4.7.3.
всего было исправлено 127 багов (http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.7.3).

MinGW на базе gcc-4.7.3 уже сейчас вы можете скачать на странице проекта (http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.7.3/).

Скажите, а boost вы не будете собирать?

к сожалению нет.

Где можно описать про последнюю сборку Qt? Что там за папка ещё одна лежит рядом?

Если вы про папку ported{32,64}, то в ней находятся программы собранные попутно с Qt - зависимости и программы необходимые для сборки самого Qt (perl,ruby,python). Выложена т.к. Некоторым пользователям они могут понадобиться.

В msys, собираемом вами, всё это есть ведь?

Это MinGW программы а не msys

Вот (http://stackoverflow.com/questions/16273561/), кстати, к старой дискуссии. Там Ruben Van Boxem замечание (http://stackoverflow.com/questions/16273561/gcc-generic-march-for-all-the-x64-platforms/16273937?noredirect=1#comment23291683_16273937) сделал. Уж не подумайте, уважаемые Алексей Павлов и niXman, что я вас лбами сталкиваю с ним.

планируются ли сборки для 4.7.2 и последующих patch релизов?

поясните суть вопроса.

На https://code.google.com/p/mingw-builds/downloads/list сборки только для 4.7.0

уже год как, MinGW-builds хостится на sf.net (http://sourceforge.net/projects/mingwbuilds/), о чем честно сообщено на основной странице: https://code.google.com/p/mingw-builds/

Понятно, я на главную не заходил ни разу.

тут (https://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/), список всех доступных релизных версий.

сборка, которая соответствует тому что есть на google code -это threads win32+sjlj?

на гуглокоде только сборки с threads=posix.

опять же, не уверен что правильно понял вопрос...

ясно. Чем лучше сейчас под винду - win32 или posix?

если использовать сборки с threads=win32, тогда окажется нерабочим все, что связанно с 'threading support library in C++11' (т.е. std::thread/std::mutex, etc...)

Здравствуйте!
Скачал сборку: "x32-4.8.0-release-posix-sjlj-rev2.7z", скомпилировал Qt и Qt Creator.
Подскажите пожалуйста, как теперь собрать отладчик, чтобы его можно потом было использовать с qtcreator?

есть два варианта:
1. скачать уже собранное отсюда (http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/Qt-Builds/).
2. собрать самому, используя скрипты qt-builds (https://github.com/Alexpux/Qt-builds).

Готовая сборка не подойдет, т.к. я собрал qt-4.8.4 + qtcreator 2.7.1 на windows 7x32, а такой готовой сборки не увидел.
Мне осталось собрать только отладчик, а как при помощи скриптов это сделать не пойму (да, и там вроде написано, что скрипт для сборки Qt5)...

заюзай скрипты. они это умеют.

А можно тогда немного поподробнее написать, как это сделать? Как собирать вручную я знаю, но вот как с помощью скриптов?

ну вот же, для пользователей же писалось:
https://github.com/Alexpux/Qt-builds/blob/master/README

Спасибо!
Уже читаю и буду пробовать.

Во-первых, если собираешься использовать скрипты Qt-builds то на данный момент лучше клонировать ветку develop.
Во-вторых, какой отладчик ты собираешься собирать? GDB? Если да то он в составе x32-4.8.0-release-posix-sjlj-rev2.7z.

Собираюсь использовать отладчик GDB, для этого уже был скачан, как раз "x32-4.8.0-release-posix-sjlj-rev2.7z" и на нём уже собрал qt 4.8.4 и qt creator 2.7.1. Посмотрев скрипты, сделал вывод, что для того чтобы они использовали выше названную версию MinGW, в файле "buildall" необходимо изменить ссылку. А вот как скомпилировать ТОЛЬКО отладчик (без сборки заново библиотеки qt) так и не разобрался. ???

Зачем собирать отладчик? Он собранный уже есть в x32-4.8.0-release-posix-sjlj-rev2.7z.

Если это файл "gdb.exe", который лежит в "MinGW\bin", то у меня при попытке отладки Qt Creator вываливает кучу ошибок.
Поправьте меня, если я не тот файл указал в  IDE.

Сам себя поправлю. По ходу дела у меня просто глючил Qt Creator. Сейчас перезагрузился и с тем самым файлом, который я выше написал, всё стало работать. :)
Спасибо alexpux и niXman за помощь!

Я хочу убрать из mingw для i686 все утилиты для компиляции под x86_64, мне они не нужны (и аналогично утилиты для i686 из дистрибутива x86_64). Правильно ли я понимаю, что достаточно удалить каталог i686-w64-mingw32 (x86_64-w64-mingw32 в случае x86_64)?

Используй dwarf и seh сборки. Они не мультилиб.
Ты не можешь просто взять и удалить каталоги из mingw - получишь нерабочую версию.

несколько дней назад состоялся релиз GCC под версией 4.8.1. сборку, на основе gcc-4.8.1 вы уже сейчас можете скачать (http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.1/) со страницы проекта.

так же, проект MinGW-builds выпустил универсальный онлайн инсталлятор, который вы можете скачать тут (http://sourceforge.net/projects/mingwbuilds/files/mingw-builds-install/mingw-builds-install.exe/download). инсталлятор получает всю необходимую информацию из этого файла (http://sourceforge.net/projects/mingwbuilds/files/host-windows/repository.txt). так что обновлять инсталлятор при выходе новых сборок - не нужно.

>>который вы можете скачать тут
ссыль забыл

ага, по идее это (http://sourceforge.net/projects/mingwbuilds/files/mingw-builds-install/mingw-builds-install.exe/download)

Именно он!

исправил.

Многие операционные системы все более уверенно смотрят в сторону замены GCC на CLang. На сколько я знаю, в Mac OS X - это уже состоявшийся факт. Во FreeBSD это планируется в 10 релизе...

Нет ли желания попробовать сварить сей тулчейн и под Виндовс? ::)

ЗЫ: Понимаю, что CLang пока молод, в тестах изредка проигрывает ощутимо. Но ... нравится его вектор развития - сперва наиболее полная поддержка стандарта C++11, потом уж оптимизация. Это привлекает.

в Clang есть неразрешимая проблема с calling convention для windows при сборке мингвом(пруф сейчас немогу найти). пока что разрабы игнорируют эту проблему.
как только поправят - будут сборки и Clang.

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

благодарен.

К стати, наталкивался на SF.net на MinGW-builds но так и не понял состав и версии
Wiki пустая, ссылка "MinGW-builds Web Site" никуда не ведёт

Чё это такое вообще не понятно.

Что это такое написано в Description на страничке Summary: http://sourceforge.net/projects/mingwbuilds/.

MinGW-builds - это сборки тулчейнов на основе mingw-w64 runtime. Являются официальными тулчейнами использующимися разработчиками Qt и включаемые в их инсталляторы.
Подробно о составе каждого тулчейна можно посмотреть на страничках загрузки: http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/.

Тулчейны собираются с помощью скриптов : https://github.com/niXman/mingw-builds.

vps, твой вопрос относится не к сборкам MinGW, а конкретной проблеме.

вчера была пересобрана версия 4.8.1 под ревизией rev2, со следующими изменениями:
- add support for Ada, ObjC and ObjC++ languages
- 32-bit GCC linked with --large-address-aware
- mingw-w64 runtime rev. 5934

находится тут (http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.1/).

niXman, коль ты знаешь как это всё собирать, подкинь ссылочку на простое и понятное для новичка руководство о том, как самому собрать под виндовоз GCC, который будет генерить код для микроконтроллеров типа AVR и ARM

сам не пробовал, посему, не уверен.
'--target=<arch>' устанавливаем в одно из допустимых значений. читаем доку (http://gcc.gnu.org/install/configure.html), и, если что не понятно, пишем в gcc-help@gcc.gnu.org

после длительных переговоров, было принято решение об объединении проектов MinGW-builds (https://sourceforge.net/projects/mingwbuilds/) и MinGW-w64 (https://sourceforge.net/projects/mingw-w64/).
целью является:
1. усиленная поддержка/фиксинг windows-specific багов/фитчей.
2. уменьшение зоопарка сборок, который, даже бывалого вводит в ступор.

проект MinGW-builds получает статус официального сборщика тулчейнов для win32/win64. (до этого момента, MinGW-builds считался персональными сборками)
проект MinGW-w64 получает официальные сборки. (до этого момента, напомню, MinGW-w64 не предоставлял официальных сборок, только персональные, за которые отвечали авторы сборок)

таким образом, проект MinGW-builds вливается в команду MinGW-w64, и перестает существовать. о точной дате прекращения поддержки/обновления MinGW-builds - я сообщу дополнительно.

вопросы?

а официальность кем определяется? gcc.gnu.org?

и ими тоже.

Добрый день! Интересно, как там у вас дела с объединением?
И еще, не планируете ли вы как-то связаться с командой Qt чтобы они официально перешли на эту (вероятно, уже объединенную) сборку mingw и выкладывали у себя на сайте сборки qt для mingw 32 и 64?

в процессе.

так и будет.

для 32 - точно будут собирать, как и сейчас. а вот для 64 - хз-хз..
зачем гадать? напишите им вопрос в development@qt-project.org ML.

А с командой "основного" mingw вы как-нибудь взаимодействуете?

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

нет. это бесперспективный проект. он должен "умереть".

у них и сейчас нет проблем с тулчейном от MinGW-builds. по крайней мере, мне о таковых не известно.

Раз уж произошло враждебное поглощение другим проектом вашего, то не знаю к вам ли вопрос.
Проблема в том, что (по крайней мере rev1, rev2 и rev3 ver4.8.1) ломаются на простом C++11-коде, когда указываю "-g" опцию для генерации отладочной информации.
Вот этот код. (http://pastebin.com/sG7BY5HZ) Он корректный.
Текст ошибки:
g++ -v:

страшно жить! ;D

по поводу ошибки: это не mingw-specific ошибка. ибо на линуксах с gcc-4.8.1 - то же самое.

какой версией у вас собирается этот код успешно?
вы баг-препорт в gcc не писали?

рапортовал:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58216

как исправить, вы поняли?

Спасибо, понял. Тогда вообще нет смысла использовать эту фичу, пока дварф не допилят.
Больше интересно как вы локализовали источник ошибки?
Где почитать как писать баг-репорты насчёт GCC?

а вы SJLJ сборку не пробовали? возможно там не будет этой проблемы...

методом исключений. начал удалять по одному методу, пока не остался всего один.

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

счастливый вы человек!.

Не подскажите, тяжело ли прикрутить tcmalloc или другой к вашей сборке?

хз, не пробовал.

пришло время сообщить о том, что слияние mingw-builds и mingw-w64 завершено!
с этого момента, сборки на странице проекта mingw-builds более обносляться не будут.

все новые сборки будут доступны на странице проекта mingw-w64, x32 (https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/) и x64 (https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/).

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

На птичьих правах, но всё ж в Евросоюз.

Для Windows 64 какую сборку порекомендуете - SEH или SJLJ?

Я порекомендую SEH.
SJLJ vs SEH - это как goto против <algorithm>

Только что скачал сборку i686 по ссылке которая парой постов выше. При выполнении собственной цели пишет следующее и полностью зависает:


команда запуска (в субшелле Far-a):


Предыдущая версия с https://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.1/32-bit/threads-posix/sjlj/ работала нормально. Файл Makefile.THT-app.Release в аттаче.

Вышел 4.8.2, ожидать ли сборку (и фикс с make) в ближайшую неделю?

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

Вот похоже (https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.8.2/threads-posix/seh/). Алексей Пушкин так тщательно скрывал своё имя...

Друзья, мне нужно собрать некоторые опенсоурсеые либы (например, GStreamer) под Винду, да так, чтобы их можно было прилинковать из UWP-приложения (https://en.wikipedia.org/wiki/Universal_Windows_Platform).

Сейчас я поверхностно знаком с UWP. Один из способов - использовать статические библиотеки для использования стороннего неуправляемого С/С++ кода, и если в них нет "запрещенных" функций (те Win32 API, что не поддерживаются UWP), то UWP приложение должно собираться в MSVS 2015. Но libc/libstd++ может быть куча таких "запрещенных" Win32 API.

Мельком видел, что свежие mingw-w64 имеют поддержку WindowsStore и чего-то там связанного с WinRT. UWP - это развитие WinRT. Кто может пояснить, что это за поддержка?

Если у кого-то есть опыт использования сторонних С-либ в UWP-приложении - делитесь, буду очень признателен.

Спасибо.