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

в скором времени начну формировать пакеты для разработчиков состоящие из компилятора(mingw), IDE(QtCreator/CodeBlock/Dev-C++/wxDev-cpp), и некоторого набора предкомпилированных библиотек(boost, Wx, Qt, OpenSsl, и еще каких-то.. понять бы что в спросе...). пакеты не будут требовать установки/настройки. распаковал - используй.

Это сообщение отредактировал(а) boostcoder - 30.7.2011, 22:16

boostcoder, кул...
ато в инете только офф.сборки да tdm, ито - 4.5.2

моя первая сборка стабильной версии gcc-4.6.1 для windows(т.е. MinGW) с полной поддержкой LTO, OpenMP, Graphite, std atomics и std threads.

скачать можно тут. бесплатно!  

при использовании классов из std threads, добавляйте опцию "-lpthread". в будущих сборках исправлю.


Это сообщение отредактировал(а) boostcoder - 31.7.2011, 17:08

Неа. Есть ещё сборки от Equation Solution. Там и 4.6 и 4.7 есть.

boostcoder, а ты можешь запилить поддержку LTO (Link-Time Optimization)?

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



в смысле "запилить" ? в этих сборках она есть. по твоему блогу проверял: http://kemiisto.blogspot.com/2010/09/lto.html

Это сообщение отредактировал(а) boostcoder - 31.7.2011, 08:20

boostcoder, извини, не посмотрел.

эм.. обнаружил такую неудобность...

если собирать коды из блога kemiisto с отключенным LTO, то линкер ругается на unresolved externals на pthread`ы.
если LTO включить - все ок.

получется что с отключенным LTO ничего не собрать.
ушел разбираться. сорри 

Добавлено через 3 минуты и 27 секунд
OpenMP линкуется как надо.

и этот код тоже:


странно... что-то я с ключами configure намутил 

Добавлено через 8 минут и 5 секунд
если отключить LTO и при этом добавить "-lpthread" - все равно линкер ругается. какие-то взаимоисключающие опции ведать указал..

и -

что-то не сходится...

kemiisto, кстати. в сборках присутствует только g++. а ты, насколько мне известно, еще и фортран юзаешь.. в принципе он собирается с полпинка, так что могу включить. вообще не включал остальные ЯП чтоб архивы сильно не росли. там только жава 150Мб занимает не в сжатом виде..

исправил.
качать тут.

скажите, кто-то тестил последнюю сборку?
я хочу сообществу GNU-gcc предложить применить мой патч в основную ветку, для корректной сборки MinGW с поддержкой всех перечисленных фитчей.

буду благодарен если кто-то попробует собрать и потестить свои реальные проекты.
спасибо.

залил новую сборку: gcc-4.7.0-snapshot-20110805

пофиксил:
1. Исправлена необходимость указывать "-lpthread" при линковке с использованием std::threads классов.
2. Исправлена ошибка линковки при использовании std::async.
3. Использована возможность указать способ линковки стандартных библиотек. По умолчанию, линкуются shared-версии. При указании линкеру флага "-static" - используются статические библиотеки.

Это сообщение отредактировал(а) boostcoder - 7.8.2011, 16:31

Что то этим откомпилированные файлы минимум 4 Мб получаются.

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

g++ -c hello.cpp
g++ -o hello hello.o

На выходе файл 3.94Mb.

Если компилить официальной сборкой 4.5.2 или вашей gcc-4.7.0-snapshot-20110805, то все нормально.

А вообще, большое спасибо за сборку.

Это сообщение отредактировал(а) Garese - 13.8.2011, 11:11

Garese, линкеру, опцию "-s" добавьте же.

Добавил, все равно великоват 600Kb.

Он по умолчанию -static подставляет походу, как это отключить?

Это сообщение отредактировал(а) Garese - 13.8.2011, 11:45

да.
4.6.1-release-lto_fixed+patched_for_nanosleep собран так, что использует только статическую линковку.
постараюсь пересобрать так чтоб была возможность указывать способ линковки.

залил новую сборку: 4.7.0-snapshot-20110815.

Исправлен баг вызывающий "зацикливание" при использовании omp_set_num_threads().
При использовании классов из std::thread`s части, необходимо добавлять линкеру флаг "-static". Иначе получим исключение. Разбираюсь... 

Добавлено Добавлено @ 11:55
В планах:
1. перейти на использование pthreads-w32, вместо используемой сейчас winpthreads.
2. разобраться со сложностями сборки версий 4.6.1-4.6.2 возникшими в следствии изменения конфигурационных скриптов в офф. репозитарии.

долгожданный релиз 4.6.1: http://code.google.com/p/mingw-builds/down...ase-20110828.7z
пора готовиться к релизу 4.6.2 

пересобрал релиз 4.6.1: http://code.google.com/p/mingw-builds/downloads/list
исправлен последний известный баг("При использовании классов из std::thread`s части, необходимо добавлять линкеру флаг "-static". Иначе получим исключение.") путем сборки компилятора без использования динамических библиотек.

с этого момента, сборка версии 4.6.1 считается стабильной и завершенной.
с этого момента, по просьбам пользователей, буду заливать сборки в виде .7z и .zip архивов.

в архив добавлены следующие компоненты:
1. GNU make-3.82
2. libpython-2.7
3. GNU gdb-7.3a

Добавлено @ 16:06
нарвался на такую новость: Intel® Cilk™ Plus is now available in open-source and for GCC 4.7!
не понял, с версии 4.7.0, Cilk™ Plus будет входить в состав GCC по дефолту, как OpenMP, или как?... но технология невероятно востребована!

такими темпами, gcc вберет в себя все лучшее.

Это сообщение отредактировал(а) boostcoder - 30.8.2011, 16:14

добавил новые сборки версии 4.7.0 содержащие ЯП: C, C++, Objective-C, Objective-C++, fortran: http://code.google.com/p/mingw-builds/downloads/list
планирую разобраться с проблемами сборки Java, и далее выкладывать сборки включающие в себя C, C++, Objective-C, Objective-C++, Fortran, Java.

Это сообщение отредактировал(а) boostcoder - 10.9.2011, 00:15

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

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

boostcoder, я правильно понимаю, что там нет 64-битных сборок?

kemiisto, да. но будут. сейчас это приоритетная задача.

Добавлено @ 22:41
вообще, в планах, создать инсталлятор, в котором юзер сможет выбрать:
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 инсталлятором.

Это сообщение отредактировал(а) boostcoder - 17.9.2011, 22:42

boostcoder, понял. Интересно будет взглянуть. 

А сложно под вынду собирать? MSYS, конечно, как минимум, нужен...

теперь нет. но по началу, когда я только задался этой целью, у меня ушло около месяца на попытки... нет, я не каждый день и не целый день этим занимался. но в сумме, все равно очень много времени ушло на эти попытки. и это я пробовал собрать в венде, на виртуалке. и, из-за того что в венде приходилось ждать по 8 часов чтоб увидеть очередную ошибку, я решил попробовать собирать в лине, кросскомпилятором. и да, помогло. в лине, все это дело собиралось в двое быстрее. в общем я однажды все таки собрал свой первый мингв. но без OpenMP+Graphite+LTO+std_threads. но кому он такой был нужен? в инете полно подобных сборок  т.е. еще немало времени ушло на это. потом, осознав неудобность того, что в лине не запустишь тесты, а переносить на венду недособранный компилятор ооочень не просто, я все же решил второй раз попытаться собрать его нативно. однажды таки получилось.

так что, в сумме, я бы сказал, месяца четыре попыток...
и да, без MSYS никуда.

Это сообщение отредактировал(а) boostcoder - 17.9.2011, 23:24

А кто какими цветовыми стилями пользуется?...
в QtCreator юзаю такое:
http://s2.ipicture.ru/uploads/20110919/vjEVC21S.png

з.ы. кто-нить знает где можно для KDevelop/Kate найти? 


Это сообщение отредактировал(а) Sahab - 19.9.2011, 22:36

Sahab, вот это щаз в тему было (про раскраску критера). Да?  

"Компиляторы и IDE(!) для C++"
какбэ понимаю, что не совсем то. Но к иде же)

Sahab, kate: Settings -> Configure Kate -> Editor Component -> Fonts & Colors.

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

Настроить цвета по готовому шаблону - дело пяти минут. Боюсь такому ленивцу предлагать гуглить, но все же: "kate color scheme", в т.ч. несколько есть на kde-look.

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

 бывал не только тут.

з.ы. не скажу что в гугле нет... но толкового совсем мало.  



Это сообщение отредактировал(а) Sahab - 20.9.2011, 14:37

залил пререлиз сборки версии 4.6.2. собственно, эта сборка является подготовительной к релизу 4.6.2, ибо сборка этой ветки осложнена правкой кучи конфигов т.к. патчи в эту ветку не принимаются.
релиз ожидается к концу этой недели. конечный список багфиксов так же пока не сформирован. какие-либо нововведения(в сравнении 4.6.1) вряд ли будут добавлены. зато исправлено больше ошибок. к тому же, мне известно только одно существенное отличие от версий 4.7.0 - в последнем, OpenMP-3.1 которая предоставляет task-based параллелизм. что, конечно, добавит еще больше возможностей применять OpenMP.

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

http://code.google.com/p/mingw-builds/downloads/list

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

в течении прошлой недели были реализованы две новые возможности:
1. explicit override control.
2. non-static data member initializers.

залил на http://code.google.com/p/mingw-builds/downloads/

залил новые сборки версий 4.6.2 и 4.7.0.
исправлен SEGFOLT при использовании std::this_thread::yield().

в скором времени выйдет первая версия mingw-env(так далее будет называться проект) включающая:

• компилятор MinGW
• IDE Code::Block, Dev-C++, wxDev-C++, QtCreator
• множество предкомпилированных библиотек

все из перечисленного будет доступно при помощи онлайн-инсталлятора.

Это сообщение отредактировал(а) boostcoder - 19.10.2011, 10:45

Вчера состоялся релиз компилятора GCC версии 4.6.2, в котором проведена работа по исправлению ошибок, регрессивных изменений и проблем с совместимостью. С момента выхода прошлой версии отмечено 115 исправлений, большинство из которых связано с устранением внесенных ранее регрессивных изменений и с улучшением поддержки спецификаций C++11. Исходные тексты компилятора можно загрузить с сайта проекта или с его зеркал.

Сборки MinGW на базе GCC-4.6.2 вы уже сейчас можете скачать на странице проекта.
Следующее обновление GCC 4.6.3 ожидается в феврале.

Это сообщение отредактировал(а) boostcoder - 28.10.2011, 11:03

залил новые сборки тестовой ветки 4.7.0 в которых впервые реализована технология Transactional Memory(кстати Intel эту фитчу реализовал довольно давно). полагаю, эта фитча станет невероятно востребована в паре с OpenMP, что позволит сделать мир многопоточных программ проще  отдельно хочется поблагодарить Red Hat inc. за "подаренную" реализацию Transactional Memory, которая, к тому же, всего три месяца назад "подарила" реализацию OpenMP-3.1.

скачать версии GCC для windows вы как всегда можете скачать тут. совершенно бесплатно  

Это сообщение отредактировал(а) boostcoder - 22.11.2011, 10:12

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

Это сообщение отредактировал(а) boostcoder - 30.11.2011, 19:50

boostcoder, имхо, лучше второй вариант.
для начала делай хост x86. Потом, если попросят, всегда можно собрать еще и x86_64.

добавил новые сборки в которых реализованы Delegating Constructors и Templates Aliases.

качаем. тестим. осваиваем.

Есть ли плагин для Notepad++, чтобы список функций, классов, методов был доступен отдельно от кода?


Это сообщение отредактировал(а) Trotil - 10.12.2011, 09:01

залил новые сборки версии 4.7.0.
разрабатываемая ветка 4.7.0 перешла в stage 3(bug fixes and docs only). все что не было в ней реализовано(а это совсем не много), будет реализовано в ветке 4.8.0.
релиз 4.7.0 обещают в феврале, после чего, ветка перейдет в stage 4(regression fixes and optimization). 4.7.1 обещают в мае.

качать тут.

Это сообщение отредактировал(а) boostcoder - 24.12.2011, 11:18

залил пререлизные сборки 4.6.3.
с этого момента, сборки поддерживают как динамическую, так и статическую линковку. сделано это для соответствия общему принципу. в связи с этим, при использовании std_threads/std_atomics, добавляйте опцию "-static" при линковке. иначе получите сегфолт. проблема известная, и девелоперы обещают ее пофиксить.

зы

оказывается, я не правильно понял. разрабатываемая ветка сначала перейдет в stage 4, и после, в феврале, ожидается релиз.
в stage 4 ветка уже перешла.

Это сообщение отредактировал(а) boostcoder - 10.1.2012, 10:20

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

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

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

качать тут.

Это сообщение отредактировал(а) boostcoder - 19.1.2012, 19:25

не к холивару будет пост, но только что в списке рассылки 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. тесты проводились в таком окружении:

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

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

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

Up.
хотя в результатах тестирования, такие результаты:
gcc-4.6.3-32: 1.38
gcc-4.6.3-64: 1.18
Intel-11-32: 1.21
Intel-11-64: 1.10
msvc2010: 1.59

тут можно скорее сказать, что gcc идет в ногу с intel, чем в ногу с msvc ;)


Это сообщение отредактировал(а) boostcoder - 19.1.2012, 19:31

Несколько раз перечитал описание данного бенчмарка - ничего не понял. Вернее не понял что это за параметр normalized run time
Вот это

перевести то перевёл, но что это значит - не понял. Зачем делить все времена (и что значит все??? сумму всех?) на лучший результат ?
Можешь разжевать для тупого ?

Можешь считать это средним результатом после проведения серии экспериментов.

Добавлено через 2 минуты и 30 секунд
Гцц оказался еще и самым тормозным в плане времени компиляции. Хотя это уже давно известно.

угу.


не нужно быть голословной.
все дело в том, что MSVC как и Intel производят сборку в несколько потоков. по умолчанию - сколько ядер. а gcc, точнее make.exe в венде работает в один поток. т.е. опция -j не дает эффекта ;)

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

и

вроде бы и время работы у tcc925 бешенное (91,1) и этот злополучный параметр плохой (5,31). Но ведь если время выполнения 91,1 сек, а отношение этого времени к лучшему = 5,3, то лучшее время 91,1 / 5,31 = 17,2. А у интела - 17,1 / 1,0 = 17,1.
Нифига не понимаю.   

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


в моих расчетах, я суммировал время работы теста(не компиляции) и поделил на кол-во тестов.

Лучшее время - 17.1, отношение времени тцц к лучшему равно 5.3. Вообще я плохо первый ответ дала, на самом деле это показатель того, во сколько раз одно хуже лучшего. Вот интел - лучший, гцц хуже в полтора раза, тцц - в пять.

Добавлено через 3 минуты и 21 секунду
Я знаю про этот баг, но гцц все равно тормоз в соотношении качество/скорость компиляции.

Ога. Он еще и интерпретировать не компилируя умеет - это главная его фишка. А к тестам его приплели просто чтобы показать насколько простое решение хуже продвинутых технологий. В пять раз всего

newbee, нет, ты чтоб не потроллить о наболевшем, не можешь.

Дохтур, у меня ничего не болит, вы о чем вообще? ;;я честно не поняла, где троллинг.

Добавлено через 8 минут и 11 секунд
Я еще чуть чуть почитала про тцц и повнимательней посмотрела статистику, так этот тцц быстрее всех компилирует - чем не повод засунуть его в эксперимент?

Сорри за тупизм. Вот говорили же мне старшие товарищи, что утро вечера мудреннее... Вот это я вчера протупил. Решил (почему-то), что для одного компилятора делалась серия экспериментов и этот злополучный коэффициент - это среднее время делить на лучшее среди этих экспериментов, а на самом деле это - время работы кода этого компилятора делить на лучшее время среди компиляторов. Теперь ясно.

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

спасибо.

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, у меня в подписи.

Это сообщение отредактировал(а) boostcoder - 2.3.2012, 00:08

Когда будут сборки mingw64 ? Можешь сделать для версии 4.6.3 ?

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

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

Это сообщение отредактировал(а) boostcoder - 2.3.2012, 22:12

boostcoder, да ладно? Они что ли собираются нестабильную версию выпустить? Или у них trunk стабильная?

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

std::regex запилили бы лучше.

Randajad, а что не так с регексами ?

полагаю, это M$ специфик. в линуксе-то он работает. попробую разобраться на досуге.

   кажется понял...
http://liveworkspace.org/code/5633b7a65228...264ebd0e7853b69

borisbn, говорят что не работает. кто-то говорит что тупо сегфолтит. я пока не проверял.

Добавлено через 41 секунду

хм.. а когда-то оно работало. в линуксе точно.

Не сегфолтит.
На простом std::regex r("\\d"); кидает std::regex_error.

Это сообщение отредактировал(а) Randajad - 15.3.2012, 14:02

Всем привет.

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

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

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

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

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


Это сообщение отредактировал(а) boostcoder - 25.3.2012, 00:37

Исправьте в первом посту пожалуйста: пишется CodeBlocks, а не CodeBlock. 

Это сообщение отредактировал(а) Randajad - 25.3.2012, 18:03

визуализация всего периода разработки 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

жду отзывов 

boostcoder, спасибо. Ждём 4.7.0 на LWS