Несколько раз было высказано мнение о том, что постить ссылки на мои сборки MinGW в некоторой теме — не хорошо. по этому, создаю отдельную тему по мотиву: http://forum.sources.ru/index.php?showtopic=337722

мои сборки, и сам проект mingw-builds является некоммерческим, открытым проектом, направленным на исправление ошибок/особенностей GCC на Windows платформе.

mingw-builds — сборки GCC для windows(т.е. MinGW) с полной поддержкой LTO, OpenMP, Graphite, std atomics и std threads.

файлы с пометкой snapshot и prerelease — не стабильные версии. в реальных проектах использовать не рекомендую. использую для тестирования новых фитчей.
файлы с пометкой release — стабильные, прошедшие тесты.


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

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

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


в скором времени добавлю сборки для i686(хост) — i686,x86_64(цели), и x86_64(хост) — x86_64,i686(цели).


надеюсь тема не нарушает никаких правил сего ресурса.

А что под своим настоящим именем не опубликуешь сборки? niXman — несерьезный псевдоним для такого серьезного дела.

Здравствуйте, Аноним, Вы писали:

А>А что под своим настоящим именем не опубликуешь сборки? niXman — несерьезный псевдоним для такого серьезного дела.
ага. и скан паспорта приложить =)

Здравствуйте, niXman, Вы писали:

X>Несколько раз было высказано мнение о том, что постить ссылки на мои сборки MinGW в некоторой теме — не хорошо. по этому, создаю отдельную тему по мотиву: http://forum.sources.ru/index.php?showtopic=337722
А чем оно от TDM отчличается?

Здравствуйте, Vain, Вы писали:
V>А чем оно от TDM отчличается?
std_threads+std_atomics в TDM отключен. это первое.
второе — TDM ооочень долго задерживает выпуск. так, к примеру, версию 4.6.0 обещали пол года. но в итоге, так и не выпустили.
третье — уже довольно давно зарелизили версию 4.6.2. у TDM ее до сих пор нет.
четвертое — фиксы багов происходят только в следующем релизе. мне же не в лом пофиксить, и тут же выложить.
пятое — я собираю и snapshot`ы.

это из основных моментов.

Здравствуйте, niXman, Вы писали:

X>четвертое — фиксы багов происходят только в следующем релизе.
А что это за фиксы? Команда из самого gcc битые релизы выкладывает? И какий смысл фиксить (с условием что это фиксы действительно компилятора), если на это способны только компетентные люди из самой команды gcc?

Здравствуйте, Vain, Вы писали:
V>А что это за фиксы? Команда из самого gcc битые релизы выкладывает? И какий смысл фиксить (с условием что это фиксы действительно компилятора), если на это способны только компетентные люди из самой команды gcc?
команда gcc к особенностям win платформы относится второстепенно.
и я не фиксю компилятор как таковой. только то, что относится к рабочему окружению win платформы. патчи шлю разработчикам. некоторые принимают, некоторые отвергают по разным причинам.

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, Vain, Вы писали:
V>>А что это за фиксы? Команда из самого gcc битые релизы выкладывает? И какий смысл фиксить (с условием что это фиксы действительно компилятора), если на это способны только компетентные люди из самой команды gcc?
X>команда gcc к особенностям win платформы относится второстепенно.
X>и я не фиксю компилятор как таковой. только то, что относится к рабочему окружению win платформы. патчи шлю разработчикам. некоторые принимают, некоторые отвергают по разным причинам.
Непонятно что такое "рабочее окружение win платформы". Это не фикс самого билда?

Здравствуйте, Vain, Вы писали:
V>Непонятно что такое "рабочее окружение win платформы". Это не фикс самого билда?
что в твоем понимании "билд"? собранная версия компилятора для конкретной платформы? если да — то gcc вообще никаких билдов не выпускает.

17.01.2012 10:02, niXman пишет:

Во-первых, спасибо.

> в скором времени добавлю сборки для i686(хост) — i686,x86_64(цели), и
> x86_64(хост) — x86_64,i686(цели).
Во-вторых, жду вот этого.

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

Intel Core-i3/i5/i7 chips are quite prevalent now, and I'm lazy, so, with no disrespect intended towards AMD and other non-Intel x86 CPUs, I ran the benchmarks only on my home PC, a 2010-vintage system with a Core i5-670 CPU that turbo boosts to 3.73 GHz. My motherboard is an Asus P7H57D-V EVO with 16 GB of DDR-3 1333 MHz RAM. The O/S is 64-bit Windows 7 Ultimate.

в пяти из десяти тестов GCC-4.6.3 незначительно отставал от MSVC.
усредненное значение пересчитанное мною таково:
GCC — 15.13
MSVC — 15.12 (т.е. MSVC на одну сотую секунды впереди)

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

Здравствуйте, niXman, Вы писали:

X>для остальных компиляторов не считал.
Похоже ICC там всех зарулил.

Здравствуйте, Banned by IT, Вы писали:
BBI>Похоже ICC там всех зарулил.
разве кто-то в этом мог сомневаться? =)

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, Banned by IT, Вы писали:
BBI>>Похоже ICC там всех зарулил.
X>разве кто-то в этом мог сомневаться? =)

Ну, прогресс не стоит на месте. Гнусь усиленно пилят и он там с ICC нормально так потягался. Тест конечно достаточно примитивный и на полноту картины вряд ли может претендовать.
Я у себя периодически (по мере выхода новых версий) устраиваю бенчмарки на числодробление с анализом нагенерённого asm в особо интересных случаях. Правда только для ICC vs MSVC.
Особенно хорошо ICC показывает себя на разного рода криптографии, там его оптимизатор дерёт MSVC как бык овцу.

Здравствуйте, Banned by IT, Вы писали:
BBI>Ну, прогресс не стоит на месте. Гнусь усиленно пилят и он там с ICC нормально так потягался.
это да. особенно хорошо прогресс заметен на показателях 4.6.3 vs 3.4.2.

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, Vain, Вы писали:
V>>Непонятно что такое "рабочее окружение win платформы". Это не фикс самого билда?
X>что в твоем понимании "билд"? собранная версия компилятора для конкретной платформы? если да — то gcc вообще никаких билдов не выпускает.
процесс сборки

Здравствуйте, Vain, Вы писали:
V>процесс сборки
какой может быть процесс сборки, если gcc.gnu.org вообще не собирают для windows?
или я вопроса не понял...

Здравствуйте, niXman, Вы писали:

V>>процесс сборки
X>какой может быть процесс сборки, если gcc.gnu.org вообще не собирают для windows?
Как это не собирают если есть таргеты для mingw? Как минимум в 4.1.2 были.

Здравствуйте, Vain, Вы писали:
V>Как это не собирают если есть таргеты для mingw? Как минимум в 4.1.2 были.
так, не собирают.

Здравствуйте, niXman, Вы писали:

V>>Как это не собирают если есть таргеты для mingw? Как минимум в 4.1.2 были.
X>так, не собирают.
т.е. ты значит фиксишь билд под windows?

Здравствуйте, Vain, Вы писали:
V>т.е. ты значит фиксишь билд под windows?
да. о чем изначально и было сказано.

скажите, кому либо в моих сборках, нужны ли Objective-C, Objective-C++, Fortran? хочу их исключить. за ненадобностью.

спасибо.

Objective-C и Objective-C++ были исключены за ненадобностью.

залил новые сборки версий 4.6.3-prerelease и 4.7.0-snapshot.

Objective-C и Objective-C++ были исключены за ненадобностью.

залил новые сборки версий 4.6.3-prerelease и 4.7.0-snapshot.

добавил новые сборки 4.6.2-release с фиксом динамической линковки при использовании std_threads.

Вчера, 1 Марта, состоялся релиз компилятора GCC версии 4.6.3, являющийся очередным баг-фикс релизом ветки компиляторов 4.6.х

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

Оригинальная новость.

P.S.
Уже сейчас вы можете скачать MinGW на базе gcc-4.6.3 из моих сборок.
Комплект состоящий из mingw-4.6.3+boost-1.49.0, у меня в подписи.

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

сегодня, основная ветка разработки GCC (trunk), форкнулась в gcc-4.7-branch. это означает, что релиз gcc-4.7.0 состоится через неделю-другую. релиз-кандидат соберу на днях.
начата работа над gcc-4.8.0.

Доброе утро. Релиз gcc 4.7.0 будет доступен для mingw, и если будет, то приблизительно в какие сроки?

Здравствуйте, unnamed32, Вы писали:

U>Доброе утро. Релиз gcc 4.7.0 будет доступен для mingw, и если будет, то приблизительно в какие сроки?
здравствуйте.
прям сейчас занимаюсь сборкой. есть сложности. по идее, сегодня-завтра.

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, unnamed32, Вы писали:

U>>Доброе утро. Релиз gcc 4.7.0 будет доступен для mingw, и если будет, то приблизительно в какие сроки?
X>здравствуйте.
X>прям сейчас занимаюсь сборкой. есть сложности. по идее, сегодня-завтра.

А какие сложности? Я собрал под cygwin без проблем.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, Шахтер, Вы писали:
Ш>А какие сложности? Я собрал под cygwin без проблем.
мне не нужна эмуляция среды(со всеми вытекающими). иначе вообще бы не собирал.

Всем привет.

Если вдруг кто не знает, <b>mingw-builds</b> — это проект предоставляющие сборки компилятора <b>GCC</b> для Windows платформы, т.е. MinGW.

Итак...
До сих пор, проект предоставлял сборки с двумя типами реализации исключений: 1)<b>dwarf</b>, 2)sjlj(<b>1</b>, <b>2</b>).
Сборки использующие dwarf, будут исключены из последующих сборок проекта <b>mingw-builds</b>.
Связанно это с двумя причинами:
1. dwarf, для windows ОС — это инородный способ реализации исключений, он не может работать правильно в windows из-за того, что реализация как С++ так и Си(<b>SEH</b>)  исключений в компиляторе MSVC использует SJLJ. В связи с этим, возникают трудноуловимые ошибки связанные с разрушением стека и пробросом/ловлей исключений между .dll модулей. Мнение разработчиков CRT для MinGW(mingw-w64) <b>тут</b>.
2. и вторая причина, вытекающая из первой — отсутствие реализации dwarf для windows-x86_64.

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

С этого момента, проект <b>mingw-builds</b> предоставляет сборки для двух хостов: 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 хоста возникли некоторые сложности. На страницу проекта пока не выгружал. Хочу одновременно.

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

Здравствуйте, niXman, Вы писали:

X>в тестировании принимали участие компиляторы: MinGW (gcc 4.6.3), Intel 2011, Microsoft 2010 Visual C/C++ Express, и др.(Tiny CC, Digital Mars, MinGW (gcc 3.4.2)). использовались следующие опции. тестировались такие проекты как: BW1D, BZIP2, CRAFTY, K2PDFOPT, LAME, MESHER, MODEL3D, RESIZER, TRANSCEND, X264. тесты проводились в таком окружении:
X>GCC — 15.13
X>MSVC — 15.12 (т.е. MSVC на одну сотую секунды впереди)

А разве MSVC Express поддерживает полную оптимизацию?

Здравствуйте, Алексей., Вы писали:

А>А разве MSVC Express поддерживает полную оптимизацию?

Конечно, там полноценный тулсет (компилятор, линкер, и т.п.), только IDE урезано, возможно еще чего-то не хватает, но всегда можно скачать недостающий SDK.

Здравствуйте, niXman, Вы писали:

X>реализация как С++ так и Си(<b>SEH</b>)  исключений в компиляторе MSVC использует SJLJ.
SEH основан на jump'aх?

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

Здравствуйте, niXman, Вы писали:

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

А Вы не могли бы всё же выложить сборку для x86? А то ручки чешутся.

http://www.xvidvideo.ru/component/docman/doc_details/8966-cross-mingw-x86x64-20120322-with-gcc-470-stable-release.html

Здравствуйте, unnamed32, Вы писали:
U>http://www.xvidvideo.ru/component/docman/doc_details/8966-cross-mingw-x86x64-20120322-with-gcc-470-stable-release.html

спасибо.
но в тех сборках хоть что-то по человечески заработало? трэды? OMP? LTO?

Здравствуйте, niXman, Вы писали:
X>но в тех сборках хоть что-то по человечески заработало? трэды? OMP? LTO?
таки да, все что касается поддержки многопоточности в стандартной библиотеке, там так и не работает. OMP все с тем же набором багов. (по идее. тесты не гонял.)

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, niXman, Вы писали:
X>>но в тех сборках хоть что-то по человечески заработало? трэды? OMP? LTO?
X>таки да, все что касается поддержки многопоточности в стандартной библиотеке, там так и не работает. OMP все с тем же набором багов. (по идее. тесты не гонял.)
Не проверял, и даже не знаю что может не работать, т.к. впервые столкнулся с надобностью порта gcc под windows. У вас как дела обстоят, все еще не побороли трудности?

Здравствуйте, unnamed32, Вы писали:
U>У вас как дела обстоят, все еще не побороли трудности?
разобрался.
пересобираю с чистого листа.
часа через четыре выгружу.

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, unnamed32, Вы писали:
U>>У вас как дела обстоят, все еще не побороли трудности?
X>разобрался.
X>пересобираю с чистого листа.
X>часа через четыре выгружу.
Отлично

Выгрузил следующие сборки:
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

жду отзывов

Здравствуйте, niXman, Вы писали:

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

X>жду отзывов
Спасибо огромное. Правда есть вопрос, а что с тредами и т.д. не так, вроде щас набросал маленький примерчик, и все робит.

Здравствуйте, niXman, Вы писали:

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

X>жду отзывов
Или в вашей сборке это пофикшено?

Здравствуйте, unnamed32, Вы писали:
U>Или в вашей сборке это пофикшено?
в моих-то — да.

есть возможность производить сборки clang для вендус. как думаете, оно надо кому-то?

Здравствуйте, niXman, Вы писали:

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

X>жду отзывов
При компиляции armadillo (2.99.1) i686-mingw32-gcc-4.7.0-release-c,c++,fortran-sjlj получил следующее:
.../armadillo_bits/Mat_bones.hpp:474:5: internal compiler error: in copy_binfo, at cp/tree.c:1250

Здравствуйте, Vzhyk, Вы писали:
V>При компиляции armadillo (2.99.1) i686-mingw32-gcc-4.7.0-release-c,c++,fortran-sjlj получил следующее:
V>.../armadillo_bits/Mat_bones.hpp:474:5: internal compiler error: in copy_binfo, at cp/tree.c:1250

напиши баг-репорт сюда: http://gcc.gnu.org/bugzilla/
как создавать ба-репорты, написано тут: http://gcc.gnu.org/bugs/

30.03.2012 17:27, niXman написал:

> V>.../armadillo_bits/Mat_bones.hpp:474:5: internal compiler error: in
> copy_binfo, at cp/tree.c:1250
>
> напиши баг-репорт сюда: http://gcc.gnu.org/bugzilla/
Я не уверен, что и под юниксом также. Юникса под рукой нет, да и навыка
разворачивания второго компилятора на нем тоже нет. Кроме того,
возможно, это баг mingw порта.
Ну и теста именно этого момента я не делал. MC VS 2010 и mingw gcc 4.6.1
(что с инсталяцией mingw идет) собирают нормально, а твои сборки 4.7.0
обломились.
Просто ты просил отзывы писать, я и написал.
Ну и возможно у тебя будет время посмотреть.

Здравствуйте, Vzhyk, Вы писали:
V>VS 2010 и mingw gcc 4.6.1
V>(что с инсталяцией mingw идет) собирают нормально
регрес, по всей видимости..

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

30.03.2012 17:54, niXman написал:

> дай ссылку на проект который пытаешься собрать.
> его сложно собрать? много зависимостей?
Да.
В понедельник уже посмотрю внимательнее. Сделаю маленький проектик для
этого момента.

30.03.2012 18:42, Vzhyk написал:

> В понедельник уже посмотрю внимательнее. Сделаю маленький проектик для
> этого момента.
Вот еще дополнительная инфа:
Для кода:

#include <iostream>

#include "armadillo"

int main(int ac, const char* av[])
{
    arma::mat x = arma::randu(1000,1000);
    arma::mat y = arma::randu(1000,1000);
    std::cout << arma::norm(x*y, "fro");

    return 0;
}

И компиляции gcc i686-w64-mingw32 (4.7.0) получил

...
[0mIn file included from d:/Viktor/temp/armadillo:124:0,
                  from d:/Viktor/temp/test_armadillo.cpp:3:
d:/Viktor/temp/armadillo_bits/Mat_bones.hpp:474:5: internal compiler 
error: in copy_binfo, at cp/tree.c:1250
...

И cообщение винды: "Entry Point Not Found: The procedure entry point
__gxx_personality_v0 could not be located in the dymamic link library
libstdc++-6.dll."

Перед компиляцией следующая переменная среды установлена:
set PATH=<path to i686-mingw32-gcc-4.7.0-release>;<path to msys>;%PATH%

02.04.2012 13:34, Vzhyk написал:

> Для кода:
>
> #include<iostream>
>
> #include "armadillo"
>
> int main(int ac, const char* av[])
> {
> arma::mat x = arma::randu(1000,1000);
> arma::mat y = arma::randu(1000,1000);
> std::cout<< arma::norm(x*y, "fro");
>
> return 0;
> }
>
>
> И компиляции gcc i686-w64-mingw32 (4.7.0) получил
>
> ...
> [0mIn file included from d:/Viktor/temp/armadillo:124:0,
> from d:/Viktor/temp/test_armadillo.cpp:3:
> d:/Viktor/temp/armadillo_bits/Mat_bones.hpp:474:5: internal compiler
> error: in copy_binfo, at cp/tree.c:1250
> ...
>
>
>
> И cообщение винды: "Entry Point Not Found: The procedure entry point
> __gxx_personality_v0 could not be located in the dymamic link library
> libstdc++-6.dll."
>
> Перед компиляцией следующая переменная среды установлена:
> set PATH=<path to i686-mingw32-gcc-4.7.0-release>;<path to msys>;%PATH%
Да, еще забыл armadillo 2.99.1.

Похоже, что это баг GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52685
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52470
И как я понял уже пофикшен:
Jason Merrill 2012-03-29 15:56:08 UTC
Fixed.
Target Milestone: 4.7.1

Когда этот фикс будет в твоих сборках?

Здравствуйте, Vzhyk, Вы писали:
V>И как я понял уже пофикшен:
V>Jason Merrill 2012-03-29 15:56:08 UTC
V>Fixed.
V>Target Milestone: 4.7.1
да, пофикшен.

V>Когда этот фикс будет в твоих сборках?
на днях соберу.

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

Архивы с собранным MinGW вы сможете скачать тут.
На данный момент скачивать нечего. Сейчас пересобираю все доступные версии. Сегодня залью.

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

Буду признателен если кто-либо попробует воспроизвести процесс сборки на своей машине и в своем окружении.
Инструкция по использованию скриптов.

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

Залил следующие сборки:
4.6.2-release(i686/x86_64)
4.6.3-release(i686/x86_64)
4.6.4-prerelease(i686/x86_64)
4.7.0-release(i686/x86_64)
4.7.1-prerelease(i686/x86_64)
4.8.0-snapshot(i686/x86_64)

Тестим, отписываемся.

Компилил вашей сборкой (и не только) простую прогу:

#include <stdio.h>

int main()
{
printf( "Hello, world!" );
return 0;
}

на выходе exe размером 44Кб, тот же lcc выдает exe 30Кб при этом туда входит и код функции printf. Если закоментить строку с printf, то gcc сделает exe того же размера, а lcc — 3Кб. Можно как-то уменьшить размер exe? Там видать слишком большой стартап код, можно его как-то уменьшить?
Я знаю что можно компилить отключив либы по умолчанию и указывать свою точку старта, но это не то, хотелось бы чтобы остались все плюшки от стартового кода.

Здравствуйте, Airog.

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

да Вы и сами можете поинтересоваться у людей причастных к MinGW: Mingw-w64-public@lists.sourceforge.net

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, Airog.

X>честно говоря, даже никогда не задумывался об этом.
X>попробую разузнать...

можно попробовать самому написать маленький стартовый код, но у меня нет его исходников, подскажи где его взять? Попробую уменьшить, убрав все не нужное

X>да Вы и сами можете поинтересоваться у людей причастных к MinGW: Mingw-w64-public@lists.sourceforge.net

можно, но я с английским не сильно дружу )

Здравствуйте, Airog, Вы писали:
A>у меня нет его исходников, подскажи где его взять? Попробую уменьшить, убрав все не нужное
CRT`ишка тут: http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-crt/crt/

Здравствуйте, niXman, Вы писали:

X>есть возможность производить сборки clang для вендус. как думаете, оно надо кому-то?

А Вы не в курсе, как у них с поддержкой форточек сейчас вообще?
Последнее, на что натыкался — нельзя было собирать DLL и все бинари за счёт статик линка были страшного размера.

Здравствуйте, niXman, Вы писали:

X>Залил следующие сборки:
X>4.6.2-release(i686/x86_64)
X>4.6.3-release(i686/x86_64)
X>4.6.4-prerelease(i686/x86_64)
X>4.7.0-release(i686/x86_64)
X>4.7.1-prerelease(i686/x86_64)
X>4.8.0-snapshot(i686/x86_64)

X>Тестим, отписываемся.

Можно статически влинковывать libgcc и libstdc++.
Будет ли такая возможность для libwinpthread?

Здравствуйте, Мишень-сан, Вы писали:

Дополнение.
Будет ли такая возможность для libwinpthread? Или возможность не линковать её?

Здравствуйте, Мишень-сан, Вы писали:
МС>А Вы не в курсе, как у них с поддержкой форточек сейчас вообще?
МС>Последнее, на что натыкался — нельзя было собирать DLL и все бинари за счёт статик линка были страшного размера.
не в курсе..

Здравствуйте, Мишень-сан, Вы писали:
МС>Будет ли такая возможность для libwinpthread? Или возможность не линковать её?
да. все либы могут линковаться статически.

Здравствуйте, niXman, Вы писали:

X>да. все либы могут линковаться статически.

Извините за дурацкий вопрос: а как? Пробовал ключи в стиле -static-lipwinpthread -static-libpthread эффекта ноль.
Сборка mingw i686 4.7.0 release, тянул 23 апреля

Спасибо.

Здравствуйте, Мишень-сан, Вы писали:
МС>Извините за дурацкий вопрос: а как? Пробовал ключи в стиле -static-lipwinpthread -static-libpthread эффекта ноль.
'-static'

Здравствуйте, niXman, Вы писали:

X>не в курсе..

Ну, было это чёрт-те когда, во времена llvm 2.8
В основном от попробовать отталкивает именно отсутствие вменяемой опакеченной версии под форточки.

Сегодня, состоялся релиз системы сборки 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 вы можете прочесть здесь.

[offtopic]
что-то не пойму как тут связаться с модераторами.
модераторы, измените пожалуйста название темы на: Сборки MinGW(GCC-win32/GCC-win64) от niXman

благодарен.
[/offtopic]

Здравствуйте, niXman, Вы писали:

X>[offtopic]
X>что-то не пойму как тут связаться с модераторами.
X>модераторы, измените пожалуйста название темы на: Сборки MinGW(GCC-win32/GCC-win64) от niXman

X>благодарен.
X>[/offtopic]

Напиши moderator@rsdn.ru или в личку кому-нибудь, многие появляются только вечером.

Здравствуйте, Ops, Вы писали:
Ops>Напиши moderator@rsdn.ru или в личку кому-нибудь, многие появляются только вечером.

напишу.
спасибо.

Здравствуйте, niXman, Вы писали:

X>есть возможность производить сборки clang для вендус. как думаете, оно надо кому-то?
Мне надо. Если особых сложностей со сборкой нет.

Несколько часов назад состоялся релиз компилятора GCC версии 4.7.1.
Это первый баг-фикс релиз для ветки 4.7.х.
Было исправлено 117 багов. Полный список вы можете обозрить тут.

Уже сейчас вы можете скачать сборки MinGW на базе GCC-4.7.1.

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

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

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

• Добавлен ключ --download, выполняющий только загрузку исходников, без сборки.
  
• Добавлен ключ --no-multilib, информирующий систему сборки собрать одноцелевой MinGW.
  
• Добавлен ключ --rev=N, использующийся для указания номера ревизии сборки.
  
• Добавлен ключ --threads=model, использующийся для указания используемой сборкой модели потоков. Доступны: posix/win32. При использовании win32 модели, функционал из std concurrency окажется недоступным. (требуется WIN-программер способный дореализовать WIN backend)
  
• Добавлен ключ --mingw-compress, использующийся для указания системе сборки сжать собранный MinGW в архив.
  
• Добавлен ключ --srcs-compress, использующийся для указания системе сборки сжать исходники используемые для сборки MinGW в архив.
  
• Добавлен патч исправляющий ошибку, возникающую при генерации компилятором кода эпилога развертывания стека и затирающую WIN32 LastError в этом скопе.
  
• С этого момента, GNU make поставляемый в составе сборок производимых проектом MinGW-builds, собирается с поддержкой job-сервера.
  
• MSYS доступный для загрузки со страницы проекта MinGW-builds обновлен. Добавлен модуль gettext для M4 макропроцессора. (качать архивы с суффиксом 'rev1')

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

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

Добрый день и спасибо кропотливый труд!

Хочу попробовать Вашу сборку, но по прочтении этой темы вынужден признать, что еще больше запутался в именовании версий. Мне нужна версия на замену "стандартного" MinGW-32 (т.е. host=i686, target=win32). Исходя из FAQ и конвенций старого сайта, я бы ожидал, что нужный мне дистрибутив будет называться i686-mingw-w32-gcc-4.7.1-release-c,c++,fortran-sjlj-rev2.zip, но я не нахожу ничего подобного. Не могли бы Вы прояснить ситуацию?

Спасибо!

Здравствуйте, fAX, Вы писали:

fAX>ожидал, что нужный мне дистрибутив будет называться i686-mingw-w32-gcc-4.7.1-release-c,c++,fortran-sjlj-rev2.zip

ну смотрите..
mingw-w64 — это название нового проекта по разработке новой CRT для 32ух и 64ех бит. ибо Вы наверняка знаете, что CRT разработанная проектом mingw.org в начале 2000ых, поддерживает только 32ух битную архитектуру, до сих пор. и поддержку 64ех битной архитектуры реализовывать не собираются, ибо эта CRT дико стара и тупикова.

Вам, нужно смотреть на первую составляющую в имени сборки: i686 или x86_64.
таким образом, если Вам нужно сборка для host=i686 и target=i686 — то качайте сборку с префиксом i686.

и да, т.к. проект MinGW-builds собирает все сборки двухцелевыми, то Вы, имея сборку для i686 хоста, можете собирать как для i686 цели(по умолчанию), так и для x86_64 цели.

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, fAX, Вы писали:

fAX>>ожидал, что нужный мне дистрибутив будет называться i686-mingw-w32-gcc-4.7.1-release-c,c++,fortran-sjlj-rev2.zip

X>ну смотрите..
X>mingw-w64 — это название нового проекта по разработке новой CRT для 32ух и 64ех бит. ибо Вы наверняка знаете, что CRT разработанная проектом mingw.org в начале 2000ых, поддерживает только 32ух битную архитектуру, до сих пор. и поддержку 64ех битной архитектуры реализовывать не собираются, ибо эта CRT дико стара и тупикова.

X>Вам, нужно смотреть на первую составляющую в имени сборки: i686 или x86_64.
X>таким образом, если Вам нужно сборка для host=i686 и target=i686 — то качайте сборку с префиксом i686.

Спасибо Вам огромное! То есть получается, что все гораздо проще, чем я себе понапридумывал!

Позвольте еще один вопрос. На сайте gcc я вычитал, что gcc 4.7 двоично несовместим с предыдущими версиями, в чем я убедился, поставив версию с сайта MinGW. Скажите, а как с двоичной совместимостью в Вашей сборке. В частности, интересует, придется мне перестраивать библиотеки Qt?

Спасибо еще раз!

Здравствуйте, fAX, Вы писали:

fAX>придется мне перестраивать библиотеки Qt?

да, придется, увы.

Здравствуйте, niXman, Вы писали:

X>есть возможность производить сборки clang для вендус. как думаете, оно надо кому-то?

Есть уже сборки?

У меня тут проблема:

$ g++ --version
g++ (MinGW-builds: http://sourceforge.net/projects/mingwbuilds/) 4.7.0
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ clang --version
clang version 3.2 (trunk 161402)
Target: x86_64-w64-mingw32
Thread model: posix

#include <iostream>

int main( int argc, char ** argv ) {
    try {
        throw std::exception();
    } catch ( std::exception & e ) {
    }
    return 0;
}

$ clang++ --verbose -static -fexceptions -o test.exe %LIBPATH% %INCLUDE% test.cpp %LIBS%
...Temp/test-967321.o:fake:(.text+0xd9): undefined reference to `_Unwind_Resume'
...Temp/test-967321.o:fake:(.eh_frame+0x63): undefined reference to `__gxx_personality_v0'

-lstdc++ есть
если убрать блок try-catch все собирается (и исключение бросается).

при этом g++ все отрабатывает нормально.
wtf? есть мнения?

Здравствуйте, Аноним, Вы писали:
А>wtf? есть мнения?


ага. написать в список рассылки clang: cfe-dev@cs.uiuc.edu

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

Здравствуйте, niXman, Вы писали:

X>вторая новость состоит в том, что расширение 'Intel Cilk-Plus' принято в транк.
офф новость: ttp://gcc.gnu.org/ml/gcc/2012-08/msg00355.html

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

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

Здравствуйте, Аноним, Вы писали:

А>У меня тут проблема:

А>

А>$ clang --version
А>

А>

А>$ clang++ --verbose -static -fexceptions -o test.exe %LIBPATH% %INCLUDE% test.cpp %LIBS%
А>...Temp/test-967321.o:fake:(.text+0xd9): undefined reference to `_Unwind_Resume'
А>...Temp/test-967321.o:fake:(.eh_frame+0x63): undefined reference to `__gxx_personality_v0'
А>

А>wtf? есть мнения?

Ты, скорее всего, взял сборку, которая использует упаднический SjLj, а __gxx_personality_v0 — это из DWARF уши.
Попробуй запустить clang-у как-нибудь так:

clang++ -cc1 -fsjlj-exceptions -S -fcxx-exceptions -fexceptions source.cpp

И увидишь, что вместо __gxx_personality_v0 теперь нужен __gxx_personality_sj0

Только это всё напрасно, т.к. clang-у ключ -fsjlj-exceptions только ARM/Darwin, а для x86 только DWARF и ни боже мой.

Скорее всего, clang никогда не будет поддерживать SjLj под x86. Ну, и правильно — тормозить же будет.

Здравствуйте, -MyXa-, Вы писали:

MX>упаднический SjLj
MX>тормозить же будет.
любопытно, какой буквально вложен смысл в эти фразы?
может ли написавший эти фразы, хоть коим образом подтвердить написанное? предоставить результаты исследования для первой, и результаты исследования/тестирования для второй...

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, -MyXa-, Вы писали:

MX>>упаднический SjLj
MX>>тормозить же будет.
X>любопытно, какой буквально вложен смысл в эти фразы?
X>может ли написавший эти фразы, хоть коим образом подтвердить написанное? предоставить результаты исследования для первой, и результаты исследования/тестирования для второй...

А что тут исследовать? Из названия же понятно, что Sj будет везде разбросан по коду, не глядя на то, полетит исключение или нет.
Вот и историческая справка имеется.
упаднический SjLj = DWARF exception handling is generally preferred to SJLJ.
тормозить же будет = For each function which does exception processing — be it try/catch blocks or cleanups — that function registers itself on a global frame list.

как я и думал.
успехов.

несколько часов назад состоялся релиз компилятора GCC версии 4.7.2.
было исправлено более 70 багов.
полный список тут.

сборки MinGW на базе GCC 4.7.2 вы уже сейчас можете скачать на странице проекта.

В проекте 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, и в особенности тем, кто тестирует сборки и сообщает о найденных ошибках.

Набрел на забавное поведение при попытке скормить std::function функции, отличающиеся соглашениями об вызове: (min-gw 4.7.0)

#include <functional>
void __stdcall fn1(){
}
void __cdecl fn2(){
}
int main()
{
        std::function< void()> fz1=std::bind(&fn1);
        std::function< void()> fz2=std::bind(&fn2);
}

Вылетает град ошибок.
И вот более минимальный код:

void __stdcall fn1(){
}
void __cdecl fn2(){
}
struct ICall{
};
template<class F> struct CCall:ICall{
};
template<class F> ICall* reg(F f){
    return new CCall<F>();
};
int main()
{
    reg(&fn1);
    reg(&fn2);
}

С ошибкой
Error: symbol `__Z3regIPFvvEEP5ICallT_' is already defined|
||=== Build finished: 1 errors, 0 warnings ===|

Здравствуйте, GreyMan, Вы писали:

GM>#include <functional>
GM>void __stdcall fn1(){
GM>}
GM>void __cdecl fn2(){
GM>}
GM>int main()
GM>{
GM> std::function< void()> fz1=std::bind(&fn1);
GM> std::function< void()> fz2=std::bind(&fn2);
GM>}

есть возможность проверить тоже самое с использованием boost::function<> & boost::bind() ?

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, GreyMan, Вы писали:

GM>>#include <functional>
GM>>void __stdcall fn1(){
GM>>}
GM>>void __cdecl fn2(){
GM>>}
GM>>int main()
GM>>{
GM>> std::function< void()> fz1=std::bind(&fn1);
GM>> std::function< void()> fz2=std::bind(&fn2);
GM>>}

X>есть возможность проверить тоже самое с использованием boost::function<> & boost::bind() ?
Буст версии 1.47 биндит функцию с соглашением __cdecl, но спотыкается на __stdcall
И самое интересное:
В указанном примере ошибки появляются, когда выполняется бинд обоих функций.
Если закоменнтить одну из строк, ошибок нет.
При этом, MS VC в случае с примерами на структурах, генерирует два разных типа. И преспокойно компилирует.

Ах да, версия 32 бита.

Здравствуйте, GreyMan, Вы писали:

GM>Буст версии 1.47 биндит функцию с соглашением __cdecl, но спотыкается на __stdcall
GM>И самое интересное:
GM>В указанном примере ошибки появляются, когда выполняется бинд обоих функций.
GM>Если закоменнтить одну из строк, ошибок нет.
GM>При этом, MS VC в случае с примерами на структурах, генерирует два разных типа. И преспокойно компилирует.

поузнаю в списках рассылки.

Еще более минималистиный пример, имхо, откуда ноги растут:
[ccode]
template<class F> struct Struct {
Struct (){};//необходимо явно объявить конструктор.
//без объявления ошибка не возникает
};
int main()
{
Struct<void __stdcall(*)()> cs;//1
Struct<void __cdecl(*)()> cc;//2
// обе строки должны находится в одном файле.
// если в разных — то ошибки не наблюдается
}
[ccode]
Сообщение об ошибке уже приводил:
Error: symbol `__ZN6StructIPFvvEEC1Ev' is already defined|
Словно что-то не различает конструктора двух разных типов.

Здравствуйте, GreyMan, Вы писали:

GM>Сообщение об ошибке уже приводил:
GM>Error: symbol `__ZN6StructIPFvvEEC1Ev' is already defined|
GM>Словно что-то не различает конструктора двух разных типов.
Не пробовали переименовать переменные? В старых версиях помню были какие-то внутренние клучевые слова, которые gcc по своему усмотрению пользовал.

Здравствуйте, Vain, Вы писали:

V>Здравствуйте, GreyMan, Вы писали:

GM>>Сообщение об ошибке уже приводил:
GM>>Error: symbol `__ZN6StructIPFvvEEC1Ev' is already defined|
GM>>Словно что-то не различает конструктора двух разных типов.
V>Не пробовали переименовать переменные? В старых версиях помню были какие-то внутренние клучевые слова, которые gcc по своему усмотрению пользовал.
Неет, имена тут не имеют отношения:

void myfoo(void(__cdecl*)()){}
void myfoo(void(__stdcall*)()){}
int main(){}

Эта ошибка вылетает даже в таком случае.
Но ведь для Винды это вполне легальная перегрузка же?

Здравствуйте, GreyMan, Вы писали:

GM>Но ведь для Винды это вполне легальная перегрузка же?
а я хз. никогда не использовал ни __cdecl ни __stdcall.
нужно соответствующую тему создать.

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, GreyMan, Вы писали:

GM>>Но ведь для Винды это вполне легальная перегрузка же?
X>а я хз. никогда не использовал ни __cdecl ни __stdcall.
X>нужно соответствующую тему создать.
VС различает такое дело. (Хотя было бы странно, если бы не различал))
Но при этом несовместимость типов по соглашению об вызовах mingw поддерживает, и присвоить не тот указатель не выйдет.
Собственно, все это не проблема, но вдруг кому-то приспичит использовать с функторами функции из DLL, которые имеют полное право иметь не то соглашение об вызовах, которое в данном компиляторе по умолчанию?))

Здравствуйте, GreyMan, Вы писали:

GM>VС различает такое дело. (Хотя было бы странно, если бы не различал))
GM>Но при этом несовместимость типов по соглашению об вызовах mingw поддерживает, и присвоить не тот указатель не выйдет.
GM>Собственно, все это не проблема, но вдруг кому-то приспичит использовать с функторами функции из DLL, которые имеют полное право иметь не то соглашение об вызовах, которое в данном компиляторе по умолчанию?))

узнаю у разрабов.
спасибо что сообщили о таком поведении.

просьба.

покажи плиз вывод команды 'gcc -v', и полный вывод сообщения компилятора об описанной ошибке. у меня сейчас нет доступа к венде.
спасибо.

Отослал в личку.

таки да, разрабы подтвердили что это windows specific баг G++.

объяснение звучит так:

The reason why g++ isn't able to distiguish between
calling-conventions for C++-function names is caused by the fact that
g++ doesn't use the calling-convention within mangled C++-name.
VC does this and so you have indeed two different signatures.

оформил баг-репорт.
жду подтверждения.

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

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

в качестве подготовки к релизу 4.8.0, были собраны сборки с использованием dwarf/sjlj/seh. (dwarf только 32бита, seh только 64бита)
найти их вы можете в поддереве testing: http://sourceforge.net/projects/mingwbuilds/files/host-windows/testing/4.8.0/

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

спасибо.

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

спасибо.

На http://www.cyberforum.ru вы обещали начать "формировать пакеты для разработчиков состоящие из компилятора(mingw), IDE(QtCreator/CodeBlock/Dev-C++/wxDev-cpp), и некоторого набора предкомпилированных библиотек(boost, Wx, Qt, OpenSsl, и еще каких-то.. понять бы что в спросе...). пакеты не будут требовать установки/настройки. распаковал — используй."
Или я совсем ослеп, или Вы решили уйти от этой практики или еще что, но на Вашей основной странице http://sourceforge.net/projects/mingwbuilds
я не найду НИ таких пакетов готовых, НИ мануала: а как поставить Ваш mingw с учетом необходимых MSYS, "предкомпилированных библиотек(boost, Wx, Qt...."
и какой-нить IDE.

Можно узнать что делается по этому поводу?

Здравствуйте, Аноним, Вы писали:
А>Или я совсем ослеп, или Вы решили уйти от этой практики или еще что, но на Вашей основной странице http://sourceforge.net/projects/mingwbuilds
А>я не найду НИ таких пакетов готовых, НИ мануала: а как поставить Ваш mingw с учетом необходимых MSYS, "предкомпилированных библиотек(boost, Wx, Qt...."
А>и какой-нить IDE.

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

касательно вопроса: менеджер пакетов уже написал. основной функционал работает. проблема в том, что менеджер пакетов написан на bash, и в MSYS, он нереально медленно работает.
и нормального тестирования все еще не производилось..

в общем, обещанное почти выполнено, приватно.
возможно, через несколько месяцев будем выдвигать это дело в публичное пользование/тестирование.

плюс в догонку хочу понять, что такое "sjlj" и "dwarf". Причем последнее есть только для 32-битной версии пакета.

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, Аноним, Вы писали:
А>>Или я совсем ослеп, или Вы решили уйти от этой практики или еще что, но на Вашей основной странице http://sourceforge.net/projects/mingwbuilds
А>>я не найду НИ таких пакетов готовых, НИ мануала: а как поставить Ваш mingw с учетом необходимых MSYS, "предкомпилированных библиотек(boost, Wx, Qt...."
А>>и какой-нить IDE.

А>>Можно узнать что делается по этому поводу?
X>очень много времени ушло на то, чтоб сделать MinGW-builds лучшими из доступных сборок MinGW. я на самом деле не предполагал, что на это может потребоваться почти целый год.

X>касательно вопроса: менеджер пакетов уже написал. основной функционал работает. проблема в том, что менеджер пакетов написан на bash, и в MSYS, он нереально медленно работает.
X>и нормального тестирования все еще не производилось..

X>в общем, обещанное почти выполнено, приватно.
X>возможно, через несколько месяцев будем выдвигать это дело в публичное пользование/тестирование.

Чтож — очень приятно видеть, что дело двигается, особенно с учетом того, что Ваш пакет признан Qt сообществом как основной.
Ну ок — пакеты — будут готовы позже. Подождем, хотя очень трудно ждать))
НО как насчет хотя бы мануала — как установить ручками то, что Вы в недалеком будущем сможете поставлять в виде пакетов?
Типа вот первый шаг — качаем то-се. Потом второй шаг — ставим-добавляем-исправляем.... И т.д.
И чтоб все шаги завершались фразой (и реальной ситуацией) "и вот теперь у вас на диске находится полная версия среды разработки, основанная на mingw и выбранной вами IDE."

Здравствуйте, Аноним, Вы писали:

А>плюс в догонку хочу понять, что такое "sjlj" и "dwarf".
в гугле полно подобной информации.
вот первое что нагуглилось: http://llvm.org/docs/ExceptionHandling.html#id7

A>Причем последнее есть только для 32-битной версии пакета.
потому, что поддержку DWARF для мингв-x86_64 не портировали.

Здравствуйте, Аноним, Вы писали:

А>НО как насчет хотя бы мануала — как установить ручками то, что Вы в недалеком будущем сможете поставлять в виде пакетов?
наверное будет мануал.
как придет время писать его, я свяжусь с Вами, надеясь на помощь. контакты оставьте.

Насколько трудоёмко включить в пакет gdc с arm целью?

Здравствуйте, glap, Вы писали:

G>Насколько трудоёмко включить в пакет gdc с arm целью?
нужно пробовать. иначе — ничего сказать не могу..
но в MinGW-builds это включено не будет, если вдруг Вы об этом думаете.

Здравствуйте, niXman, Вы писали:

X>но в MinGW-builds это включено не будет
точнее: оно возможно когда-то и будет включено, но не с arm целью.

к тому же, несколько месяцев назад, в списке рассылки GCC, поднимался вопрос об интеграции кодов gdc в gcc. но я не следил за тредом, так что не знаю, к чему оно пришло...

Здравствуйте, niXman, Вы писали:

X>к тому же, несколько месяцев назад, в списке рассылки GCC, поднимался вопрос об интеграции кодов gdc в gcc. но я не следил за тредом, так что не знаю, к чему оно пришло...

Мне окружение библиотечное вообще не нужно. Всё будет прокинуто через c++ код.

Так давно хочу применить D в реальном проекте, но вечно какие-то проблемы. Сейчас вот нужно сразу собирать и под 86 и под arm один код под виндой. В общем я особо и не надеюсь, что это получится, но вдруг кого-то это тоже заинтересует.

вчера состоялся релиз gcc-4.8.0.
уже сейчас вы можете скачать сборки MinGW на базе gcc-4.8.0 со страницы проекта.
в 4.8.0 для windows платформы, появилась возможность использовать SEH(1, 2). но, из-за патентных ограничений, эта возможность доступна только в x86_64 сборках.

Если ввести команду perl -MSVN::Core -e'print "ok\n";', то выведется сообщение об ошибке

Can't load '/usr/lib/perl5/site_perl/5.8/msys/auto/SVN/_Core/_Core.dll' for module SVN::_Core: dlopen: Win32 error 126 at /usr/lib/perl5/5.8/msys/DynaLoader.pm
line 230.
at /usr/lib/perl5/site_perl/5.8/msys/SVN/Base.pm line 59
BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8/msys/SVN/Core.pm line 5.
Compilation failed in require.
BEGIN failed--compilation aborted.

Примерно такое же сообщение об ошибке выводится при попытке ввести git svn rebase

Если посмотреть зависимости _Core.dll, то выясняется, что она зависит в том числе от файла, которого в сборке нет.
Не подскажете, где взять этот файл для 64 битного Windows?

Здравствуйте, Аноним, Вы писали:

А>Can't load '/usr/lib/perl5/site_perl/5.8/msys/auto/SVN/_Core/_Core.dll'
я, честно говоря, вообще не вижу этой dll`ки %)

А>Примерно такое же сообщение об ошибке выводится при попытке ввести git svn rebase
говорит: "Can't locate Git/SVN.pm"
этого, я тоже не вижу.

попробую разузнать...

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, Аноним, Вы писали:

А>>Can't load '/usr/lib/perl5/site_perl/5.8/msys/auto/SVN/_Core/_Core.dll'
X>я, честно говоря, вообще не вижу этой dll`ки %)

Может я как-то не так выразился. Файл _Core.dll находится в архиве
external-binary-packages/msys+7za+wget+svn+git+mercurial+cvs-rev13.7z

Относительно корня архива путь будет msys/lib/perl5/site_perl/5.8/msys/auto/SVN/_Core .

Здравствуйте, Аноним, Вы писали:

А>Может я как-то не так выразился. Файл _Core.dll находится в архиве
А>external-binary-packages/msys+7za+wget+svn+git+mercurial+cvs-rev13.7z
уже понял. у меня rev11.

Я посмотрел Portable Msys git. Там есть этот файл, но переписывание его в директорию bin в msys из mingw-builds ситуацию не исправляет.
Может быть это потому, что в msys из mingw-builds хоть и нет файла LIBAPR-0-0.DLL, но есть файл libapr-1.dll .
Может дело в том, что _Core.dll должен был зависеть именно от файла libapr-1.dll, а при сборке что-то перепуталось?

Здравствуйте, Аноним, Вы писали:

А>Я посмотрел Portable Msys git. Там есть этот файл, но переписывание его в директорию bin в msys из mingw-builds ситуацию не исправляет.

да, я вчера тоже понял что этой dll`ки не хватает. в добавок, LIBAPR-0-0.DLL тянет с собой еще несколько dll`ок, я их тоже скопировал, и в результате получаю сегфолт:
MSYS-1.0.17 Build:2011-04-24 23:39
Exception: STATUS_ACCESS_VIOLATION at eip=66DB13DD
eax=00000000 ebx=104D2144 ecx=10020370 edx=01011007 esi=000016B8 edi=ADADEDFE
ebp=0028EB78 esp=0028EB60 program=D:\msys\bin\perl.exe
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function Args
0028EB78 66DB13DD (104D2144, 0028EBA4, 66DF00D4, 00000000)
0028EBA8 66DEDAC0 (104D2144, 104DBB88, 10020370, 10020370)
0028EBD8 56C58D86 (104D2144, 1048C9EC, 00000002, 10571C48)
0028EC08 56C6414A (103EB108, 103EB108, 0028EDA8, 56C044C5)
0028EC18 56C538C8 (0028ED70, 00000000, 00000000, 00000000)
0028EDA8 56C044C5 (1048C89C, 00000006, 00000000, 00000000)
0028EDC8 56C07CBB (1048C89C, 00000000, 0028EEC8, 00000000)
0028EEE8 56C07989 (0000000B, 1048C848, 10067808, 10067808)
0028EFB8 56C3A2FA (0000020D, 10492108, 00000000, 00000000)
0028F008 56C35AE4 (00000001, 0000020D, 00000000, 104921C8)
0028F088 56C2E865 (103D86C8, 00000006, 0028F0B8, 56C79216)
0028F0B8 56C993D7 (00000000, 00000000, 00000000, 00000C6E)
0028F188 56C9A743 (103E9708, 103E9708, 0028F328, 56C044C5)
0028F198 56C538C8 (0028F2F0, 00000000, 00000000, 00000000)
0028F328 56C044C5 (103E19A4, 00000006, 00000000, 00000000)
0028F348 56C07CBB (103E19A4, 00000000, 0028F448, 00000000)
End of stack trace (more stack frames may be present)

и тут мои идеи заканчиваются %)

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, Аноним, Вы писали:

А>>Я посмотрел Portable Msys git. Там есть этот файл, но переписывание его в директорию bin в msys из mingw-builds ситуацию не исправляет.

X>да, я вчера тоже понял что этой dll`ки не хватает. в добавок, LIBAPR-0-0.DLL тянет с собой еще несколько dll`ок, я их тоже скопировал, и в результате получаю сегфолт:
X>MSYS-1.0.17 Build:2011-04-24 23:39
X>Exception: STATUS_ACCESS_VIOLATION at eip=66DB13DD
X>eax=00000000 ebx=104D2144 ecx=10020370 edx=01011007 esi=000016B8 edi=ADADEDFE
X>ebp=0028EB78 esp=0028EB60 program=D:\msys\bin\perl.exe
X>cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
X>Stack trace:
X>Frame Function Args
X>0028EB78 66DB13DD (104D2144, 0028EBA4, 66DF00D4, 00000000)
X>0028EBA8 66DEDAC0 (104D2144, 104DBB88, 10020370, 10020370)
X>0028EBD8 56C58D86 (104D2144, 1048C9EC, 00000002, 10571C48)
X>0028EC08 56C6414A (103EB108, 103EB108, 0028EDA8, 56C044C5)
X>0028EC18 56C538C8 (0028ED70, 00000000, 00000000, 00000000)
X>0028EDA8 56C044C5 (1048C89C, 00000006, 00000000, 00000000)
X>0028EDC8 56C07CBB (1048C89C, 00000000, 0028EEC8, 00000000)
X>0028EEE8 56C07989 (0000000B, 1048C848, 10067808, 10067808)
X>0028EFB8 56C3A2FA (0000020D, 10492108, 00000000, 00000000)
X>0028F008 56C35AE4 (00000001, 0000020D, 00000000, 104921C8)
X>0028F088 56C2E865 (103D86C8, 00000006, 0028F0B8, 56C79216)
X>0028F0B8 56C993D7 (00000000, 00000000, 00000000, 00000C6E)
X>0028F188 56C9A743 (103E9708, 103E9708, 0028F328, 56C044C5)
X>0028F198 56C538C8 (0028F2F0, 00000000, 00000000, 00000000)
X>0028F328 56C044C5 (103E19A4, 00000006, 00000000, 00000000)
X>0028F348 56C07CBB (103E19A4, 00000000, 0028F448, 00000000)
X>End of stack trace (more stack frames may be present)

X>и тут мои идеи заканчиваются %)

У меня в зависимостях LIBAPR-0-0.DLL только MSYS-1.0.DLL. Остальное — майкрософтовские dll, которые в системе уже есть.
Но MSYS-1.0.DLL в msys из mingwg builds отличается от MSYS-1.0.DLL из portable git по размеру.

Я не очень хорошо ориентируюсь в теме, но повторю свои подозрения, что в сборке из mingwg builds
используется набор библиотек libapr* другой (новой) версии, а _Core.dll слинкован с dll старой версии.

И по идее надо пересобрать _Core.dll .

Скажите, как собирается msys из mingw builds? Есть исходники?