Выгрузил следующие сборки:
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 в рамках проекта MinGW-builds под версией 0.1.0.
Из основных изменений произошедших с момента первого коммита, можно отметить следующие:

• Добавлен ключ --preload, заставляющий систему сборки сначала скачать все исходники, и только потом собирать. Необходим для одновременной сборки сразу нескольких версий.
• Добавлен ключ --dwarf, информирующий систему сборки использовать DWARF вместо SJLJ. При этом, доступна сборка только для i686 хоста, и только для i686 цели.
• Для каждой версии GCC, отныне, отдельный конфигурационный файл.
• Аргументы командной строки более не зависят от порядка написания.
• Логи сборки более не вставляются в архив со сборкой.
• С этого момента, архивы со сборками снова содержат суффикс используемой сборкой реализации исключений.
• Msys, со всеми необходимыми для сборки MinGW тулзами(7z+wget+svn+git+mercurial+cvs), вы теперь можете скачать на странице проекта.
• Добавлен патч исправляющий ошибку, возникающую при генерации компилятором кода развертывания стека и использованием GetLastError() в этом скопе.
• Добавлены следующие тесты: 1)тест POSIX-RT функций, 2)тест С++11 sleep_for/sleep_until функций, 3)тест GetLastError() при развертывании стека.

Инструкцию по использованию системы сборки MinGW-builds вы можете прочесть здесь.

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

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

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

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

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

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

недавно, в транк, был влит патч реализующий SEH для Win64: 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
это означает, что gcc, начиная с версии 4.8.0 будет поддерживать 'Cilk-Plus'. тот, кто знаком с этим расширением при использовании Intel компилятора, понимает, насколько это расширение необходимо для разработчиков многопоточных алгоритмов/программ.

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

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

я, право, уже и не знаю как реагировать на подобные посты %)
ладно, когда вопрос стоИт в том, использовать 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 впереди.
[/офтопик]