| Summary: | новый mingw | ||
|---|---|---|---|
| Product: | LINUX@Etersoft | Reporter: | Синицын Иван <ivan> |
| Component: | Общее | Assignee: | Евгений Синельников <sin> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P5 | CC: | boris, lav, pav, sin, stas |
| Version: | не указана | ||
| Target Milestone: | выпуск 1.0 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Заявки RT: | Связано с: | 1601 | |
| Дата напоминания: | |||
| Bug Depends on: | |||
| Bug Blocks: | 3166 | ||
| Attachments: | Проверка на наличие HAVE_ICONV_H в binutils/config.in | ||
|
Description
Синицын Иван
2008-06-06 18:45:44 MSD
Хорошо бы вообще понять статус проекта, где 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 |