необходима последняя версия mingw. Вроде бы в него вносили изменеия для поддержки Vista. Сейчас проект UniOffice скомпилированный в mingw по слухам в Vista не работает.
Хорошо бы вообще понять статус проекта, где mainstream и о чём он думает в плане нормальных заголовочных файлов из IDL.
MinGW довольно не целый... ест предложнеия что стоит обновить сразу, а что наоборот -лучше не трогать: i386-mingw32msvc-0.0.6-alt1.src.rpm i386-mingw32msvc-binutils-2.17.50.0.7-alt2.src.rpm i386-mingw32msvc-gcc-3.4.5-alt2.src.rpm i386-mingw32msvc-libiconv-1.9.2-alt4.src.rpm i386-mingw32msvc-libjpeg-6b-alt2.src.rpm i386-mingw32msvc-libogg-1.1.2-alt3.src.rpm i386-mingw32msvc-libpng-1.2.8-alt2.src.rpm i386-mingw32msvc-libssl-0.9.8a-alt1.src.rpm i386-mingw32msvc-libvorbis-1.1.0-alt2.src.rpm i386-mingw32msvc-libxml2-2.6.20-alt1.src.rpm i386-mingw32msvc-libxslt-1.1.14-alt1.src.rpm i386-mingw32msvc-pkgconfig-0.15.0-alt4.src.rpm i386-mingw32msvc-runtime-3.11.3.8-alt1.src.rpm i386-mingw32msvc-SDL-1.2.11-alt1.src.rpm i386-mingw32msvc-SDL_mixer-1.2.5-alt1.src.rpm i386-mingw32msvc-SDL_net-1.2.5-alt1.src.rpm i386-mingw32msvc-smpeg-0.4.4-alt1.src.rpm i386-mingw32msvc-zlib-1.2.1.2-alt2.src.rpm Кроме того, нужно уточнить какие из этих пакетов в orphaned: i386-mingw32msvc-gettext-0.14.1-alt4.src.rpm i386-mingw32msvc-libflex-2.5.4a-ipl17alt.src.rpm i386-mingw32msvc-libtiff-3.7.0-alt1.src.rpm i386-mingw32msvc-SDL_image-1.2.3-alt1.src.rpm i386-mingw32msvc-wxWidgets-2.6.3-alt1.src.rpm стоит срочно поднять и, заодно, обновить. Некоторые обновления сделаны в рамках #1601 (http://bugs.etersoft.ru/show_bug.cgi?id=1601) - нужно будет проветь всё остальное...
(In reply to comment #2) > MinGW довольно не целый... ест предложнеия что > стоит обновить сразу, а что наоборот -лучше > не трогать: > i386-mingw32msvc-0.0.6-alt1.src.rpm > i386-mingw32msvc-binutils-2.17.50.0.7-alt2.src.rpm > i386-mingw32msvc-gcc-3.4.5-alt2.src.rpm > i386-mingw32msvc-runtime-3.11.3.8-alt1.src.rpm Пока нужны только эти, потому что у нас основная цель собирать чисто WinAPI-шные программы, к которым не нужны дополнительные библиотеки.
Собран i386-mingw32msvc-binutils-2.18.50-alt0.tp20080109.1.src.rpm с поддержкой gettext (aka ICONV at config.h). Результат лежит в git.etersoft и git.alt. Чтобы сложить в сизиф, ждём пока починят инкаминг...
Created attachment 606 [details] Проверка на наличие HAVE_ICONV_H в binutils/config.in
Сборка всё равно не имеет HAVE_ICONV_H, соответственно перекодирование в windres не работает. Предлагается в спек добавить проверку наподобие приложенной (только может быть проверять уже config.h).
ни в i386-mingw32msvc-binutils-2.18.50-alt1.src.rpm ни в i386-mingw32msvc-binutils-2.18.50-alt0.tp20080109.bld1.i586.rpm не работает. надо сделать так, чтобы если define не определён сборка вообще проваливалась...
(In reply to comment #7) > ни в i386-mingw32msvc-binutils-2.18.50-alt1.src.rpm > ни в i386-mingw32msvc-binutils-2.18.50-alt0.tp20080109.bld1.i586.rpm > > не работает. надо сделать так, чтобы если > define не определён сборка вообще > проваливалась... > Как вы проверяете? В сборочной среде, я видел этот define заданным... Я перепроверю это в hasher...
(In reply to comment #8) ... > > не работает. надо сделать так, чтобы если > > define не определён сборка вообще > > проваливалась... > > > > Как вы проверяете? См. attachment к этой баге. > В сборочной среде, я видел этот define > заданным... Я перепроверю это в hasher... Приложи наконец патч, приложенный к данной баге. Ну почему надо так делать и так проверять, игнорируя уже готовые схемы по проверке наличия HAVE_ICONV, и в течение года держать неработающим компилятор ресурсов? Я уже два раза вручную собирал, но при каждом очередном обновлении неработающего пакета это стиралось.
(In reply to comment #8) > В сборочной среде, я видел этот define > заданным... Я перепроверю это в hasher... > Да... Поскольку тестов у меня не было, а hasher меняет среду, пропажа дефайна не обнаруживалась... без hasher собирается с нужными дефайнами... (In reply to comment #9) > (In reply to comment #8) > ... > > > не работает. надо сделать так, чтобы если > > > define не определён сборка вообще > > > проваливалась... > > > > > > > Как вы проверяете? > См. attachment к этой баге. > Эта проверка ничего выявить не может... Она всегда будет проваливаться, поскольку после распаковки в файле binutils/config.in HAVE_ICONV_H всегда будет отсутствовать. Он появляется позже, когда пройдёт сборка intl, если она будет подцеплена, причём в другом файле. > > В сборочной среде, я видел этот define > > заданным... Я перепроверю это в hasher... > Приложи наконец патч, приложенный к данной > баге. Ну почему надо так делать и так > проверять, игнорируя уже готовые схемы по > проверке наличия HAVE_ICONV, эта схема не рабочая... > и в течение года держать неработающим > компилятор ресурсов? согласен... посыпаю голову пеплом... я беспечно полагал, что оно работает... и то, что в hasher'е сборка проходит иначе в упор не замечал... > Я уже два раза вручную собирал, но при > каждом очередном обновлении неработающего > пакета это стиралось. > В hasher'е ему чего-то не хватает...
(In reply to comment #10) ... > Да... Поскольку тестов у меня не было, а hasher > меняет среду, пропажа дефайна не > обнаруживалась... без hasher собирается с > нужными дефайнами... Хм. ... > Эта проверка ничего выявить не может... > Она всегда будет проваливаться, поскольку > после распаковки в файле binutils/config.in HAVE_ICONV_H > всегда будет отсутствовать. Он появляется > позже, когда пройдёт сборка intl, если она > будет подцеплена, причём в другом файле. Я помню только что там всё очень как-то не прямо. ... > > проверять, игнорируя уже готовые схемы по > > проверке наличия HAVE_ICONV, > > эта схема не рабочая... Эх, ну возможно. Тогда надо вставить ifndef error прямо в код, где собирается wrc, чтобы точно видеть, что сборка идёт правильно.
(In reply to comment #11) > (In reply to comment #10) > ... > > Да... Поскольку тестов у меня не было, а hasher > > меняет среду, пропажа дефайна не > > обнаруживалась... без hasher собирается с > > нужными дефайнами... > Хм. > ... > > Эта проверка ничего выявить не может... > > Она всегда будет проваливаться, поскольку > > после распаковки в файле binutils/config.in HAVE_ICONV_H > > всегда будет отсутствовать. Он появляется > > позже, когда пройдёт сборка intl, если она > > будет подцеплена, причём в другом файле. > Я помню только что там всё очень как-то не > прямо. > Да, я нашёл... Нужно заменить HAVE_ICONV_H на HAVE_ICONV в коде... > ... > > > проверять, игнорируя уже готовые схемы по > > > проверке наличия HAVE_ICONV, > > > > эта схема не рабочая... > Эх, ну возможно. Тогда надо вставить ifndef error > прямо в код, где собирается wrc, чтобы точно > видеть, что сборка идёт правильно. > > Теперь осталось выяснить чего не хватает в hasher для сборки встроенного gettext. Он просто не цепляется на проверках ./configure, и соответственно вложенные ./configure скрипты не запускаются, а сборка проходит без iconv.
собран и находится на пути в сизиф пакет binutils-2.18.50-alt2, в котором эта ошибка должна быть исправлена. Просьба протестировать... Для ускорения процесса проверки в /var/ftp/tmp/sin залит тестовый пакет: i386-mingw32msvc-binutils-2.18.50-alt2.i586.rpm
Установлен, используется и работает. [lav@builder ~]$ rpm -q i386-mingw32msvc-binutils i386-mingw32msvc-binutils-2.18.50-alt2
