Здравствуйте, 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 бита.