Журнал ошибок, проявившихся при разработке проекта Bombono DVD

Pазработка современного ПО построена по модульному принципу. Так, Bombono DVD использует такие проекты, как Boost, Gtk, SCons и другие (всего 10 явных зависимостей, есть и неявные). Однако помимо преимуществ наследуются недостатки и ошибки, включая будущие. С некотого момента я решил завести журнал заметок, в который записываю технические проблемы, проявившиеся в ходе разработки, которые зависели/зависят не от меня (но решать-то все равно пришлось).

Смысл в том, чтоб на основе полученных данных более объективно подходить к выбору с кем "дружить", а с кем не "дружить".¹ Критерием попадания в список являются все случаи, когда ошибка/поведение/смена API/ABI/... проявилась или добавилась уже после того, когда соответствующий функционал уже прочно задействован в проекте.²

Список

 SCons: 
- с версии 2.0.1 стал вылетать при работе нелатинскими названиями файлов
- несколько раз менял свое поведение до версии 1.2.0; однако благодаря природе Python выходы находились.
- INSTALLSTR, начиная с версии 1.0 может принимать только строковые значения (не функции) - явная
  ошибка.
- расчет md5 путем чтения содержимого файла в строку; при гигабайтовом файле валился авторинг
 GraphicsMagick:
- отсутствие функции OpenCache() в новых версиях сильно попортило нервы; к тому сложности в узнавании
 какая версия GM используется бесит.
 Дистрибутивы:
- замена toolame -> twolame не дает возможности сделать одну версию для всех дистров.
- убрали /proc/scsi/devices из Debian Sid, пришлось изучать исходники ядра. (2 дня потратил).
 Gtk:
- диалог-помощник мой поломали (в Karmic, Sid) - 2 места
- синхронизацию ломали (в Hardy) между текущей вкладкой и текущим пунктом в меню Go.
- GtkButton - чего-то поменяли в стилях по умолчанию и значки на них перестали показываться
- GtkAssistant:
  - убрали возможность устанавливать страницу до show_all()
  - поменяли порядок OnApply и OnPrepare (делать что ли нечего!)
- GtkDialog - провозился целый день с открытием диалога, если в нем есть метка со ссылкой (бесконечный цикл)
- GtkFileChooser (c gtk >= 2.30.0):
  - выпадение из-за неправильного мониторинга
  - set_filename() не работает в паре c get_filename() для SELECT_FOLDER 
 GCC:
- ужесточили препроцессор так, что код Boost (1.33) перестал компилиться (починил)
 Winff:
- неправильно генерит видео для DVD (опция -target *-dvd должна быть всегда)
 Totem: 
- с версии 2.27.1 авторы перестали поддерживать xine backend.
 FFmpeg:
- c версии 0.6 опция -formats разбита на 2, -formats и -codecs
- c версии 0.6 поменяли принцип отображения потоков (спасает опция -map)
- в будущей 0.7 убрали -padX, а вместо нее — -vf pad=w:h:x:y:black ; само по себе не страшно, но
  учитывая, что в Packman/openSUSE, например, используют нестабильную версию, то так и хочется взять и ...
- в ffmpeg/libav >= 0.7 поменяли имена функций, включая dump_format->av_dump_format, av_open_input_file->avformat_open_input и т.д.,
  смысл ошибочных кодов (ушел AVERROR_NOFMT)
- в версиях libavcodec 53.4.x-53.9.x есть ошибка, портящая размеры для h.264, в процессе вызова avcodec_open() (попало в Ubuntu Oneiric);
  хочется взять и наказать автора патча
- прямой доступ, в частности, к ff_codec_bmp_tags закрыт => линковка не производится; узнать имя проблемного кодека стало сложнее
- сюрпризы libav 0.8:
  - качество кодирования сломали в libav 0.8 => сломали в ffmpeg 0.9, но в ffmpeg 0.10
    уже исправлено
  - libav завел свой конвертор, avconv (ffmpeg теперь там только для виду)
  - поменяли параметр -ab => -b:a
  - -newaudio убрали, теперь все делается через параметр -map
  - в ffmpeg заменили точку в выводе "Stream #0.1: Audio" на ":", теперь "Stream #0:1: Audio"
    (мелочь, а неприятно)
  - закрыли доступ к ffurl_register_protocol() (политика)

 MS Windows:
- GetStdHandle(STD_OUTPUT_HANDLE) возвращает мусор под XP и 2000, если процесс не присоединен к консоли
  (но практически всегда этим мусором оказывается "магическое" значение 0x00010001); в документации же 
  (http://msdn.microsoft.com/en-us/library/ms683231) утверждается, что будет возвращен нуль;
  в 7-ке поведение поправили (стало так, как описано в документации)
- в 7-ке системные вызовы kernel32.dll реализованы в kernelbase.dll, и вызов реально идет так:
  GetStdHandle()->kernel32.dll->api-ms-win-core-processenvironment-l1-1-0.dll(чистая прокся!)
  ->kernelbase.dll. Смысл усложнять все это - разве что для тех, кто реально хочет знать, 
  что происходит, но не имеет доступа к исходникам. Aх да, ставить "палки в колеса"
  программистам - любимое занятие Microsoft'а же!
- в одной весьма популярной операционке сигналы есть только для вида; пользоваться ими практически
  невозможно, и вот почему:
  - послать из одного процесса в другой можно только 2 сигнала, SIGINT(Ctrl-C) и SIGBREAK(Ctrl-Break),
    все остальные работают только внутри одного процесса
  - это будет работать, только если оба процесса присоединены к одной и той же (!) консоли
  - целенаправленная посылка сигнала работает только для SIGBREAK 
    (GenerateConsoleCtrlEvent(CTRL_BREAK_EVENT, pid)), и только если процесс, которому посылают
    сигнал, был создан с флагом CREATE_NEW_PROCESS_GROUP; в ином случае сигнал пошлется всем 
    процессам, присоединенных к консоли (включая того, кто посылал)
  Вывод: какую-либо инфу лучше передавать по-другому, например, с помощью именованных труб
  (CreateNamedPipe())
- почему стандартная библиотека C++ от MSVC не гут:
  - std::streamoff 32-битный, потому работать с файлами >= 2GB затруднительно (исправлено только
    в vs2010)
  - стандартная библиотека собрана без флага (компилятора) /vd2; последний нужен для полноценной
    поддержки С++ в компиляторе, и, если он используется (что, вроде как, естественно), то 
    линковать код с MSVC STL нельзя (теряется бинарная совместимость, будут неисправимые ошибки, 
    например, при использовании iostreams)
  Вывод: STLPort
- для паралелльной компиляции есть ключ /MP, но линковщик от MS можно запускать только один 
  (он требует эксклюзивный доступ к PDB); более того, и компилятор в это время не должен работать