Сборки mingw

[Alex Custov]

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

i686-mingw32-gcc-4.6.3

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

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

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

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

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

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

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

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

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

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

[niXman]

mingw-builds его нет, почему?

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

в каждый бинарник?

нет.

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

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

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

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

Они смотрят в сторону x86_64

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

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

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

[Alex Custov]

при загрузке системы?

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

[niXman]

при загрузке системы?

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

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

[niXman]

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

[niXman]

В проекте 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
Скриншот поясняющий назначение каждой составляющей в имени сборки.

2) Проект изменил структуру каталогов. Скриншот поясняющий новую структуру каталогов.
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, и в особенности тем, кто тестирует сборки и сообщает о найденных ошибках.

[alexpux]

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

[niXman]

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

были пересобраны все сборки версии 4.7.2 с суффиксом 'rev1', в связи с двумя(1, 2) добавленными патчами для make, и в связи с появлением в проекте пайтона собственной сборки.

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

[Dukales]

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

[niXman]

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

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

нужно ли указывать библиотеки -lgomp -lpthread явно для опции -fopenmp

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

Будет ли работать для ваших сборок -D_GLIBCXX_PARALLEL?

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

[Dukales]

Просмотрите пожалуйста эту тему.

[niXman]

вчера, разработчики Qt приняли решение относительно официального MinGW, используемого для сборки QtSDK, и поставляемого в составе QtSDK.
и все же, их выбор пал на MinGW-builds, чему я несказанно рад! это наша(проекта MinGW-builds) маленькая победа, надеюсь что не последняя :yes3

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

[Dukales]

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

[carrygun]

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

[niXman]

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

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

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