Russian Qt Forum
Ноябрь 22, 2024, 13:51 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Russian Qt Forum > Forum > Компиляторы и платформы > Компиляторы > Сборки mingw
Страниц: 1 2 [3] 4 5 ... 10   Вниз
« предыдущая тема следующая тема »
  Печать  
Автор Тема: Сборки mingw  (Прочитано 100638 раз)
Alex Custov
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2063


Просмотр профиля
« Ответ #30 : Сентябрь 04, 2012, 00:24 »
Цитата: niXman от Сентябрь 04, 2012,  00:03
какую конкретно?

i686-mingw32-gcc-4.6.3

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

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

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

Цитата: niXman от Сентябрь 04, 2012,  00:03
почему размер больше? - банально, из-за более агрессивной оптимизации. о чем собственно пишут в релизнотс к каждому выпуску компилятора.

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

Цитата: niXman от Сентябрь 04, 2012,  00:03
этим вы скорее тестировали скорость вашего харда, ибо динамический резолв символов в dll`ках таких размеров - та еще волокита %)

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

Цитата: niXman от Сентябрь 04, 2012,  00:03
но тролли же почему-то пришли к пониманию того, что дефолтный тулчейн дико устарел. им-то можно верить, как думаете?

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

Я желаю проекту победить и все дела, но я хочу иметь конкретную информацию, может и мне стоит перейти на mingw-builds даже несмотря на  увеличение размера бинарника.
Записан
niXman
Гость
« Ответ #31 : Сентябрь 04, 2012, 00:38 »
Цитировать
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.
« Последнее редактирование: Сентябрь 04, 2012, 00:48 от niXman » Записан
Alex Custov
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2063


Просмотр профиля
« Ответ #32 : Сентябрь 04, 2012, 00:59 »
Цитата: niXman от Сентябрь 04, 2012,  00:38
при загрузке системы?

при загрузке программы
Записан
niXman
Гость
« Ответ #33 : Сентябрь 04, 2012, 01:02 »
Цитата: Alex Custov от Сентябрь 04, 2012,  00:59
Цитата: niXman от Сентябрь 04, 2012,  00:38
при загрузке системы?

при загрузке программы
именно. вот ты первый раз запускаешь программу, и символы резолвятся. система при этом сохраняет только граф ссылок меж dll модулей, и только до тех пор, пока на твою dll`ку ссылается хотя бы один другой модуль/программа. если никто не ссылается, система удаляет информацию о символах. и с этого момента, информация хранится только в кеше, и только до тех пор, пока ее кто-нибудь не вытеснит.
Записан
niXman
Гость
« Ответ #34 : Сентябрь 10, 2012, 13:38 »
после нескольких дней тестов и переписки, тролли склоняются к тому, чтоб не использовать готовые сборки, а собирать самим используя мои скрипты.
но это еще не окончательное решение...
Записан
niXman
Гость
« Ответ #35 : Октябрь 06, 2012, 19:28 »
В проекте 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
Гость
« Ответ #36 : Октябрь 25, 2012, 17:47 »
Со следующих билдов mingw-builds будет поставляться с полноценным Python-2.7.3, который будет собираться из исходников вместе со сборкой, в поддиректории "opt". С этим Python будет линковаться gdb.
На данный момент код для сборки Python из исходников с помощью mingw добавлен в репозиторий. Существует несколько проблем после решения которых все сборки будут комплектоваться Python собственной сборки.
Записан
niXman
Гость
« Ответ #37 : Ноябрь 05, 2012, 09:34 »
как и обещалось ранее, проблемы со сборкой пайтона решены(благодаря Алексу).

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

думаю, через несколько недель тестов, будет релиз 0.4.0.
Записан
Dukales
Гость
« Ответ #38 : Декабрь 06, 2012, 07:52 »
Скажите пожалуйста: при сборке чего-либо (например Qt в qmake.conf переменная QMAKE_{CXX,L}FLAGS_EXCEPTIONS_ON) какой из флагов -mthreads / -pthread необходимо указывать для каждой сборки (или любой флаг для каждой?)? Также интересует вопрос, нужно ли указывать библиотеки -lgomp -lpthread явно для опции -fopenmp (и работает ли она вообще в вашей сборке?) в случае, когда необходимо указывать -mthreads? Будет ли работать для ваших сборок -D_GLIBCXX_PARALLEL?
Записан
niXman
Гость
« Ответ #39 : Декабрь 06, 2012, 08:38 »
Цитировать
при сборке чего-либо (например Qt в qmake.conf переменная QMAKE_{CXX,L}FLAGS_EXCEPTIONS_ON) какой из флагов -mthreads / -pthread необходимо указывать для каждой сборки (или любой флаг для каждой?)?
достаточно указать '-pthread'

Цитировать
нужно ли указывать библиотеки -lgomp -lpthread явно для опции -fopenmp
нет. все необходимые флаги и библиотеки, устанавливаются/подключаются автоматом.

Цитировать
Будет ли работать для ваших сборок -D_GLIBCXX_PARALLEL?
вы о параллельных алгоритмах? если "да" - то они работали. (кстати, добавляю в сборки тест для проверки параллельных алгоритмов, а то что-то я совсем забыл про них)
Записан
Dukales
Гость
« Ответ #40 : Декабрь 06, 2012, 09:25 »
Просмотрите пожалуйста эту тему.
Записан
niXman
Гость
« Ответ #41 : Январь 23, 2013, 15:38 »
вчера, разработчики Qt приняли решение относительно официального MinGW, используемого для сборки QtSDK, и поставляемого в составе QtSDK.
и все же, их выбор пал на MinGW-builds, чему я несказанно рад! это наша(проекта MinGW-builds) маленькая победа, надеюсь что не последняя :yes3

хочу выразить благодарность от лица авторов проекта(я и Alexpux) всем пользователям наших сборок, за баг-репорты, рекомендации, и просто за фид-бэк.
спасибо вам!
Записан
Dukales
Гость
« Ответ #42 : Январь 24, 2013, 19:36 »
И вам спасибо. Извините, конечно, за мой фидбэк.
Записан
carrygun
Гость
« Ответ #43 : Январь 25, 2013, 05:16 »
Не известно еще когда ожидать официальной сборки Qt5 на mingw?
Записан
niXman
Гость
« Ответ #44 : Январь 25, 2013, 08:57 »
Цитата: carrygun от Январь 25, 2013,  05:16
Не известно еще когда ожидать официальной сборки Qt5 на mingw?
нет. по пока что, глянь в конце страницы:
http://qt-project.org/wiki/MinGW-64-bit

или взять предкомпилированное здесь:
http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/Qt-Builds/
Записан
Страниц: 1 2 [3] 4 5 ... 10   Вверх
  Печать  
« предыдущая тема следующая тема »
 
Перейти в:  


Страница сгенерирована за 0.199 секунд. Запросов: 22.