А где функция setmode и констанда O_BINARY? a52dec без них сломался...
На системе, которая работала полтора года, взялся запустить обновление (блин, дёрнуло же...)
В результате сломалася установка a52dec. Жалуется на неопределённый O_BINARY (поиском по этому термину на форуме нашёл http://www.gentoo.ru/node/13587 - но эта тема ничего не прояснила, хоть и находится почему-то в разделе "решёные").
Алгоритм возникновения ошибки выяснил:
- конфигуратор смотрит по наличию хедера io.h (естественно, находит в /usr/include)
- сборка при наличии найденного файла включает его и вызывает setmode с O_BINARY
Просто определить O_BINARY в 0 - не прокатило, - стало ругаться на отсутствие функции setmode.
Поиск по хедерам обнаружил эти сущности только в хедерах wine (может можно и их заюзать - но это совсем уже куда-то влево).
Проблему решил однострочным патчем configure.in:
-AC_CHECK_HEADERS([sys/time.h sys/timeb.h io.h])
+AC_CHECK_HEADERS([sys/time.h sys/timeb.h])
(соответственно - патч в файл, копия ебилда в локальном оверлее с этим патчем - и успешная сборка)
В общем - мир успешно собирается дальше, но осадок остался:
г-н Гугль утверждает, что функция, в общем-то, достаточно стандартная. И я ума не приложу, куда она вдруг пропала в gentoo.
Или может она уже устарела и её выбросили - "а мужики-то не знают"?
В общем - если кто в теме - просветите...
- Для комментирования войдите или зарегистрируйтесь
vinogradov
Какую версию собирал? Где логи, где emerge --info?
У меня нет файла /usr/include/io.h (какому пакету он принадлежит?) и a52dec-0.7.4-r6 прекрасно собирается.
Соответственно вопрос: после обновления системы до актуального состояния ошибка имеет место быть?
Логи сборки в данном случае я фактически изложил
- autotools ищет хедер io.h. По его наличию определяет макрос HAVE_IO_H в сишном хедере.
- в коде условная компиляция - при определённом HAVE_IO_H включается хедер io.h, а ниже вызывается для stdout setmode(O_BINARY).
Поскольку в io.h не определены ни O_BINARY, ни функция setmode - компилятор вылетает с ошибкой (в данном случае - о том, что O_BINARY не определена).
Константу я искал командой find /usr/include | xargs grep 'O_BINARY' - чтобы понять, где же она может быть.
Ошибка, в общем-то, появилась при попытке обновить систему "до актуального состояния".
Первая неудачная попытка обновления была в январе. До этого она стояла с мая прошлого года.
А сейчас - очередная попытка emerge -uDN @system. Благодаря пропатченному ебилду она удалась, сейчас обновляются по цепочке 400 пакетов @world.
У вас очевидно - нет файла, нет и проблемы.
Где лог ошибки?
Где лог ошибки?
Не грусти, товарищ! Всё хорошо, beautiful good!
imho, не правильно обновлял
imho, не правильно обновлял 'старую' систему.
начинать надо с тулчейна
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
Хы... А может сразу со stage 1 начать? :)
Просто с последнего emerge -uDN @system @world прошло полтора года (в ноутбуке сгорела лампа подсветки LCD - и он на это время превратился в файловый/скан/принт-сервер; обновлять не было надобности).
emerge --sync и последующий просмотр "что бы такого обновить - emerge -uDNp @system @world" продемонстрировал список из примерно пяти сотен кандидатов на обновление. Некоторые - с блокировками. Некоторые - с изменёнными лицензиями и прочим. В общем - эти авгиевы конюшни и разгребаю.
Данный случай - единственный, когда пришлось спуститься до патча ебилда.
/
Полтора года.
Гарантированно налетаешь на
-e world(http://www.gentoo.org/doc/en/gcc-upgrading.xml).Про perl'ы/python'ы пока не говорю.
Во избежание подобных проблем рекомендую хотя бы раз в месяц-другой (если совсем лениво --- третий) находить время на обновиться. Так будет проще.
ЗЫ: При обновлении второстепенных, притягиваемых по зависимости пакетов с _таким_ интервалом между обновлениями проще их снести, чем патчить ебилды.
Первоочередная задача: получить актуальный
system.:wq
--
Live free or die
vinogradov написал(а):В
это досовские(виндовые) функции. связанные с двойным символом конца строки в текстовых файлах \r\n в DOS.
В Linux их просто нет. как и io.h.