сегодня, основная ветка разработки GCC (trunk), форкнулась в gcc-4.7-branch. это означает, что релиз gcc-4.7.0 состоится через неделю-другую. релиз-кандидат соберу на днях.
начата работа над gcc-4.8.0.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, unnamed32, Вы писали:
U>Доброе утро. Релиз gcc 4.7.0 будет доступен для mingw, и если будет, то приблизительно в какие сроки?
здравствуйте.
прям сейчас занимаюсь сборкой. есть сложности. по идее, сегодня-завтра.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, unnamed32, Вы писали:
U>>Доброе утро. Релиз gcc 4.7.0 будет доступен для mingw, и если будет, то приблизительно в какие сроки? X>здравствуйте. X>прям сейчас занимаюсь сборкой. есть сложности. по идее, сегодня-завтра.
А какие сложности? Я собрал под cygwin без проблем.
Здравствуйте, Шахтер, Вы писали: Ш>А какие сложности? Я собрал под cygwin без проблем.
мне не нужна эмуляция среды(со всеми вытекающими). иначе вообще бы не собирал.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Если вдруг кто не знает, <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.
С этого момента, проект <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 хоста возникли некоторые сложности. На страницу проекта пока не выгружал. Хочу одновременно.
Всем спасибо.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, 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>Сборка для i686 уже готова. Со сборкой для x86_64 хоста возникли некоторые сложности. На страницу проекта пока не выгружал. Хочу одновременно.
А Вы не могли бы всё же выложить сборку для x86? А то ручки чешутся.
Здравствуйте, niXman, Вы писали: X>но в тех сборках хоть что-то по человечески заработало? трэды? OMP? LTO?
таки да, все что касается поддержки многопоточности в стандартной библиотеке, там так и не работает. OMP все с тем же набором багов. (по идее. тесты не гонял.)
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
