Наверное несовсем по разделу, все-таки мне нужно научится собирать релизы в Win32, но все-же. Сделал довольно много попыток собрать сорцы новой версии компилятора, используя MinGW-gcc 3.4.2 для сборки и MSys 1.0 для запуска скриптов конфигурации, но каждый раз находились какие-то проблемы на различных этапах. Поэтапно, что я делал: MinGW был поставлен в каталог c:/MinGW, MSys в c:/MSys/1.0, сорцы gcc-4.0.1 в c:/MSys/1.0/src/gcc-4.0.1 (или /src/gcc-4.0.1, далее srcdir). Сначала запускал скрипты конфигурации в папках srcdir/gcc, srcdir/libiberty, srcdir/fixincludes, srcdir/intl и srcdir/libcpp. Параметры configure следующие: --with-gcc --with-gnu-ld --with-gnu-as --build=mingw32 --host=mingw32 --target=mingw32 \ --prefix=/mingw --enable-threads --disable-nls \ --enable-languages=c,c++ --disable-win32-registry --disable-shared \ --with-gcc-version-trigger=/src/gcc-4.0.1/gcc/version.c Последним собственно конфигурируется srcdir/configure из каталога srcdir/build-mingw32, и запускается сборка через: make -f srcdir/build-mingw32/Makefile BOOT_CFLAGS="-O2 -fssa" bootstrap из каталога srcdir. Проблемы в основном бывают с исчезновением слэшей из путей в командах выполняемых скриптами, иногда не упорядочено генерируются параметры для make, что тоже приводит к остановке процесса. Кто-нибудь может подсказать более надежный, простой и автономный способ сборки пакетов подобных gcc, или указать на допускаемые мной ошибки?
Хмм... Веселая эта тема, если честно. Собрать можно. Правда, надо по дороге и руками аккуратно обходить issues msys и mingw. В основном первого. Реже - второго. Наиболее типичная проблема, из-за чего останаливается билд - gcc из mingw не переваривает пустого пути в -I. И сразу же падает. Еще куча приколов по дороге.... Но собрать можно. По крайней мере 3.4.3 я собирал.
Скачай Dev-C++ с http://www.bloodshed.net. У них там все уже собрано и более или менее нормально работает. Зачем мучиться-то?
Ну, скажем так, у них там ничего не собиралось. Они взяли готовый mingw и все. А человек хочет собрать gcc 4.0.1. Кстати, согласно официальному заявлению одного из разработчиков mingw32, они не будут собирать gcc 4.x, до тех пор, пока x не станет == 1.
aSL Спасибо за наводку. Все-же дело это муторное, как я погляжу, хотя и проходимое. Надо к тому-же будет поправить файлы Makefile.in, в сторону правильного порядка аргументов (-f $(FILE) в первую очередь). И основная системо-зависимая проблема в конфигурировании: сначала путь, скажем /src/gcc-4.0.1/gcc преобразуется в C:\MSys\1.0\src\gcc-4.0.1\gcc, и при использовании превращается в C:\MSys1.0srcgcc-4.0.1gcc что в итоге и дает ошибку. Непонятно в общем зачем было получать абсолютный путь, да еще и формате Win9x (NT работает и с путями типа - /c/msys/1.0/bin если задавать их в PATH). SDragon В том то и прелести всего мазохизма, что при сборке на своей машине, ты можешь задать любые параметры оптимизации. Но мне кроме того хочется научится вносить в компилятор свои изменения.
Естественно. Ибо одиночный '\' символ является префиксом для форматного ввода Соответственно, в путях его крайне желательно экранировать. Только мне интересно, где ты такой путь нашел.... Когда я собирял 3.4.x, то все было без подобных вещей... Общий принцип сборки - собирать из отдельного каталога. И все будет нормально. А вообще, RTFM Могу еще порекоммендовать почитать про сборку cfrontend под mingw32 на http://llvm.cs.uiuc.edu/docs/CFEBuildInstrs.html (там общие инструкции, а про mingw - ищи в llvm-dev maillist).
aSL Вот в том-то и проблема, что сам этот путь получается в недрах скрипта configure/Makefile, видать там используются какие-то API функции, после чего строка не приводится в нормальный вид (фигурирует как $$r в Makefile). Сборка в исключительно отдельной папке, у меня особенно не получается - приходится в любом случает выполнять отдельные конфигуры в соответсвующих подкаталогах (fixincludes, libiberty, etc), иначе сборка рвется с мессаждем типа "No rule for make target some..." За ссылку сенкс, почитаю как до нормальной сетkи дорвусь.
