Embedded Sphinx, или поиск на роутере

Поисковый сервер Sphinx (sphinxsearch) позиционируется как система, весьма неплохо масштабируемая под высокие нагрузки и большие объёмы индексов. В целом это неплохо — но иногда под рукой нет машины с 16-ядерным процессором и 256Гб оперативки. А что делать, если ядро всего одно? А если и с объёмом памяти не очень? А если это не сервер и даже не средний PC, а вообще роутер на SoC, с далеко не самым быстрым «камнем», и где всего 32Мб оперативки, да и ту нужно делить с другими процессами и системой? Взлетит ли в таком случае поисковик? Будет ли работать? Оправдано ли?
Да, взлетит. Да, будет работать. Да, вполне оправдано.

Что если задействовать роутер?

Настало время, когда мне совсем-совсем надоели периодические подвисания старенького роутера (DI-624) и я сменил его на WRT-160NL. Пощупал интернеты, поискал описания возможностей обновки… И уже на следующий день заменил стоковую прошивку на dd-wrt. Подцепил внешний hdd, пошаманил — и получил скромный NAS-файлопомойку. Пошарился ещё в интернетах, прочитал про optware, попробовал — и на том же внешнем hdd завёлся дополнительный софт уже для самого роутера. Transmission — пожалуйста; lighttpd — запросто! php? Без проблем! Хм… а библиотечный сайт взлетит? Да, взлетел. А если его базу mysql прямо в роутер засунуть? Ух ты, получилось! Правда, сборка mysql сильно обгрызенная; из таблиц только MyISAM — но всё равно, работает!

А поиск?

Это что ж выходит — торренты теперь качает сам роутер; файлопомойку и даже сайт обслуживает он же… Единственное, чего не хватает — поиск sphinx. Он по-прежнему крутится на десктопе. А что если и его на роутер?..
Да. Как выяснилось — собирается, запускается, работает. Хорошо работает!
Роутер я позже сменил на Asus RT-N16, а теперь на NetGear WNDR-4300. Прошивку с dd-wrt сменил на openwrt. Но sphinx по-прежнему на ней живёт.

Как собрать свой софт под роутер?

Конечно, покуда есть консоль и возможность собирать скрипты, создать прогамму можно многими разными способами. Некоторые из них — весьма твердолобые. Примерно как устанавливать программу из исходников на deb или rpm-based дистрибутиве с помощью ./configure && make && make install: возможно, соберётся и даже взлетит — но масштабируемость и приспособленность к поддержке практически нулевая. Поэтому используются более цивилизованные способы. Я имел дело с двумя системами сборки/публикации под роутер. Их и опишу.

Optware

С него началось моё знакомство с альтернативным софтом для сторонних прошивок.
Если вкратце, optware — это софт, целиком сосредоточенный в ветке /opt. Отсюда и название. Например, демон, устанавливаемый в optware, будет лежать где-нибудь в /opt/usr/sbin, пошаренные библиотеки закинет в /opt/usr/lib, конфиги будет ожидать в /opt/etc, а скрипты запуска кинет в /opt/etc/init.d. Если на целевой системе всего 4мб флэш-памяти, и все забиты прошивкой — не беда! Нужно всего лишь смонтировать каким-либо образом /opt из другого места — и мы в шоколаде! Можем ставить optware и работать! Этим другим местом может быть, например, внешняя флэшка (вставленная в имеющийся порт usb). Или даже карточка SD, припаянная «на коленке» к любым контактам внутри роутера, состоянием которых мы способны программно управлять (например, светодиоды питания, активности, статуса — на вывод; кнопки wps и reset — на ввод. Дальше всё примерно как в ардуине или другом МК — мы «мигаем» указанными контактами в нужном порядке, изображая работу шины SPI, и считываем «нажатия кнопки». А карточка SD это понимает, и так мы получаем доступ к её содержимому буквально "через светодиоды и кнопку". ). Ну или даже внешняя сетевая ФС, подмонтированная в роутер из работающей Windows по протоколу SMB. Правда, в этом случае пропадает смысл роутера как небольшого автономного компьютера, умеющего полностью обслуживать свои сервисы.
Optware когда-то было частью разработки свободной прошивки openwrt, однако позже отделилось в независимый проект, ввиду того, что собираемые там пакеты — полностью независимы и самодостаточны. Нужные для их работы стандартные библиотеки (libc в виде uclibc) также собираются и располагаются в optware. Это позволяет запускать очень многие приложения, практически не заботясь о возможностях и особенностях прошивки конкретного устройства.
Минусами данного подхода является то, что заработает всё же не всё. Например, так нельзя собрать и подключить модули ядра. Также привязка к собственным стандартным библиотекам подразумевает их загрузку в память вместе с уже имеющимися стоковыми библиотеками прошивки, а значит — повышенные требования к оперативной памяти, которой на роутере и так не очень много. Наконец, мы получаем не заточенную под конкретную железку сборку, а пакет для «универсального среднестатистического роутера» — это примерно как программа под i386 (которую вы запускаете при этом на своём крутом core i7): многие возможности конкретного процессора/платформы игнорируются и откатываются к legacy. И тем не менее, optware — вполне работающее решение.
Optware обычно собирается кросс-компилятором на linux-based хосте (я, например, собираю на ubuntu 12.04). Зачекаутив svn-репозиторий проекта, вы сразу получите и исходники, и файл README с дальнейшими инструкциями (кому любопытно — вперёд!).

Openwrt

Это уже целая отдельная прошивка, которая полностью заменяет оригинальную стоковую. С OpenWrt мне пришлось связаться, когда стало ясно, что возможностей ddwrt+optware недостаточно. Начитавшись хабровских статей про «умный дом» я решил понемногу автоматизировать разную домашнюю электрику. Выбрал z-wave, купил «свисток» и присоединился к облаку z-wave.me. Однако держать включённым десктоп ради связи домашней автоматизации с облаком — слишком расточительно. Тем более, что в моём роутере был не один, а целых два usb-порта! Но… свисток не завёлся. Нужного модуля ядра (cp21xx) в прошивке не оказалось. Собрать софт такого рода в optware оказалось невозможно. Пересобрать всю прошивку dd-wrt — тоже совсем нетривиальная задача (ужасная система! Моего терпения так и не хватило, чтобы настроить тулчайн, удовлетворить все зависимости и добиться-таки успешной сборки!). Openwrt для моего роутера (rt-n16) изначально не поддерживался, однако в тот момент уже нашлись патчи, позволившие сделать вполне рабочую прошивку. Так и распрощался с dd-wrt в пользу «ещё более свободной» прошивки.
Чем хорош openwrt? Да тем, что настраивается всё. Смотрим на минусы optware, и выкидываем их из головы. Никаких дублирующихся библиотек (собираем софт прямо под имеющуюся прошивку). Никаких проблем с модулями ядра (обычный полноценный linux. Захотел экзотический «свисток»? Пожалуйста! Захотел воткнуть 3G-модем и взять из него интернет? Запросто!). Софт можно оптимизировать под имеющуюся платформу (и компилятор при сборке задействует те возможности, которые есть в чипе конкретно вашего роутера, а не откатится к legacy).
Наконец, стОит сказать, что openwrt на самом деле никак не противоречит optware. Просто он гибче и удобнее. Однако если с предыдущей прошивки сохранился раздел /opt, то имеющийся там софт скорее всего отлично запустится в новом openwrt. Пересобирать ничего не нужно! (правда, все минусы его изолированности optware при этом останутся).

Embedded Sphinx — что от него нужно?

Масштабируемость сфинкса впечатляет! Достаточно рассмотреть и оценить ачивки на страничке 'powered by' проекта. Индексы на миллиарды документов; нагрузка в полмиллиарда запросов в день — вполне рабочие числа. Но это всё High Load на серьёзных машинах или даже кластерах, с шустрыми процессорами и морем оперативной памяти. А как насчёт масштабируемости в другом направлении? Мало памяти, непонятный процессор и диск? Оказывается, не так плохо. На нативной не x86 платформе сфинкс вполне нормально собирается (и проходит внутренние тесты) на Raspberry Pi. Однако если рассмотреть детали, то кроме другой архитектуры всё остальное в «Малинке» очень даже неплохо. Целых 256-512Мб оперативки! А сфинксу это и нужно! Ведь практически весь его «секрет успеха» заключается в максимальном использовании доступного железа. Он вовсе не ориентирован на философию «640Кб хватит всем», а совсем наоборот; стремится максимально следовать «модным» конфигурациям и использовать их возможности на полную катушку.
Подешевела память? Забенчим и упихаем в неё весь индекс!
Вошли в моду в продакшне новые модные SSD с впечатляющим временем доступа? Окей, поиграемся, попробуем — и, может, снова перетрясём внутренние стратегии и форматы, «шоб всё летало».
Причём, это вовсе не расточительство вида «раз у нас новый шустрый проц — значит можем себе позволить эти три гига строчек сортировать пузырьком, из скрипта, написанного на бейсике», а совсем наоборот; разумные оптимизации, реализованные опытными (экс)геймдев-разработчиками и проверенные бенчами.
И куда, спрашивается, тут соваться со своим допотопным «недокомпьютером», который только и умеет байтики пересылать из одного кабеля в другой? Ну, собственно, а почему бы и нет?
Разумеется, подразумевается кросс-компиляция (некоторые умудряются собирать и запускать нативный тулчайн прямо на роутере — но я не очень готов к такому подходу). Раз кросс-компиляция — значит, многие внутренние тесты автотулзов (сфинкс конфигурируется именно ими) останутся в стороне и нужно будет как-то подсказать тулчейну, что мы имеем на борту железки.
Итак, чтобы запустить сфинкс на небольшой железке нужно сперва обдумать некоторые моменты, связанные с «миниатюрностью» целевой платформы.

Оптимизируем требования к памяти

Как удовлетворить прожорливость (вернее, «масштабное отношение») сфинкса к оперативной памяти? Тут всё достаточно просто. Сфинкс не расходует ресурсы «просто так»; его «прожорливость» напрямую зависит от поставленной задачи и от объёма индекса. Именно он, по большей части, занимает место в памяти. Значит, чем меньше индекс — тем меньше требования к памяти.
В оперативную память загружается словарь (файл .spi) и блобы атрибутов (файлы .spa, .sps, .spm). Оценивая размеры этих файлов, можно сделать достаточно точный прогноз будущей «прожорливости».
Если будет совсем туго — можно избавиться от атрибутов и включить опцию «словарь-на-диске». Тогда всё будет медленно и печально, зато целиком на диске. Впрочем, можно ничего не отключать, а просто подключить swap-раздел. Влезет в память — будет «летать». Не влезет — автоматом уйдёт в своп и само придёт к варианту «медленно и печально, зато работает!»

Тип индекса?

Я брал обычный. Со словарём keywords (просто crc уже устарел). RT не нужен хотя бы потому, что сами данные не нужно менять в real-time; достаточно периодической переиндексации (а так-то да, при надобности «взлетит» и rt). Это значит, что одного демона searchd недостаточно, а потребуется ещё и индексатор (indexer).

Связь с источником данных?

Что ещё? Нужна поддержка нужного источника данных (в нашем случае — mysql). До недавнего времени с этой поддержкой были определённые «грабли», связанные с архитектурой самого сфинкса — а именно, то что он состоит из «мегабиблиотеки» libsphinx и небольших исходников, реализующих непосредственные тулзы indexer, searchd и т.д. При этом практически весь функционал работы с индексами (включая их создание из источников данных) находится в libsphinx. «Грабли» поддержки источников заключаются в том, что собрав сфинкс с поддержкой mysql, все бинари сфинкса через общую мегалибу оказываются зависимыми от libmysqlclient. На серьёзной машине это не проблема, но вот на роутере иметь в бинаре зависимость от библиотеки, которая прилинкована «просто так», но совершенно не нужна для работы — расточительно! Тут есть два варианта: сделать две сборки; одну с поддержкой mysql, вторую — вообще без поддержки индексации. Из первой взять indexer, из второй — всё остальное. Второй вариант появился недавно — он просто загружает все нужные внешние библиотеки явно (через dlopen). В этом случае о лишних зависимостях можно забыть: indexer подгрузит библиотеку, когда ему будет надо; searchd вообще не будет её трогать.

Как запускать демона?

Классический способ реализован в самом сфинксе. Это двойной форк — сперва отцепляемся от активного терминала, потом создаём новую рабочую сессию — и вот мы уже живём в фоновом режиме, не имеем консоли и не реагируем на нажатия Ctrl+C в терминале. Записываем свой pid в pid-файл — и всё, мы стали полноценным демоном. Вроде всё ок, но это приходится реализовывать КАЖДОМУ демону в системе. А зачем дублировать код на open-source системе? Вот и умные мужики подумали-подумали и придумали upstart — он вообще не требует от «подопытного» процесса уметь становиться демоном, а просто сам держит его в фоне, хранит pid-файл в общепринятом месте и заодно реализует «сторожевую собачку», перезапускающую демона в результате внезапного падения. К слову, в своё время из-за этого возникли проблемы запуска сфинкса через upstart — две слишком умные программы всё никак не могли договориться. В итоге правильный вариант из-под upstart — запускать с опцией '--nodetach' и следить за запущенным процессом (а не его форками). При этом сфинкс не считает себя демоном, а всё фоновое управление падает на upstart).
В случае с embedded, однако, никаких проблем с upstart нет, покуда что optware, что openwrt пользуются классическими rc.d-скриптами. Иными словами — никаких спец.флагов не нужно; своей жизнью сфинкс будет управлять сам.

Куда девать логи?

Изначально сфинкс ведёт общий лог демона (упал-встал-ротировался), а также отдельный лог всех запросов. Ясно, что на роутере писать что-то во флэш-память, да ещё и без контроля размера — будет подобно самоубийству. Поэтому в качестве логов указываем в конфиге 'syslog', а также не забываем добавить --with-syslog (впрочем, он теперь и так включён по дефолту) при конфигурировании сборки. В результате весь вывод посыплется в системный лог, которым мы уже будем рулить на уровне системы самого роутера. А дальше есть несколько вариантов, в зависимости от возможностей прошивки. На некоторых (вроде старого DIR-300 с очень маленьким флэшем) логи проще вообще не вести. На других кусочек хранится в кольцевом буфере прямо в памяти, и может быть прочитан из консоли командой logread. На третьих перенаправляется по udp на сервер в локалке «который может». Но в любом случае — это больше не проблема сфинкса!

Конфигурирем и собираем!

Все вопросы работы демона на роутере вроде решили. Теперь настало время сделать сборку!

Обманываем autotools

Сфинкс конфигурируется с помощью autotools. ./configure-скрипт, запускаемый перед сборкой, честно проутюжит нашу сборочную систему и узнает, какой у нас компилятор, какие функции поддерживаются, какова архитектура, каков порядок байт (LSB или MSB). Проблема в том, что практически все эти тесты затронут не целевой роутер, а ту систему, где мы запускаем тулчейн. Поэтому путь только один — подсказать конфигурации «правильные ответы». Делается это с помощью переменных окружения. Например, если ./configure проверяет доступность функции qsort, то можно дать нужную «подсказку», определив переменную ac_cv_func_qsort перед запуском ./configure. Например, выполнив перед сборкой export ac_cv_func_qsort=no — ./configure будет считать, что функции qsort у вас нет. Соответственно, сконфигурированный таким образом пакет будет либо использовать собственную реализацию, либо вообще сломается при сборке (ха-ха!).
Для сборки embedded sphinx «явных подсказок» нужно совсем немного. Вот они все…

• sphinx_cv_unaligned_ram_access (yes/no) — название говорит само за себя. Вкратце — внутренний формат индексов у сфинкса — сжат, выровнен по одному байту. Если вдруг потребуется взять DWORD из такого файла (загруженного в память), а он окажется лежащим по нечётному адресу — на некоторых архитектурах (например, sparc) это приведёт к крешу! Распознать ситуацию можно либо читая даташиты на целевую платформу; либо методом «научного тыка» — собрав все возможные (целых два!) варианты и попробовав запустить на целевой системе. (Технические детали: если unaligned access невозможен, то вместо того, чтобы просто взять DWORD с нужного указателя, будет задействован вызов memcpy, чтобы скопировать нужные 4 байта с произвольного адреса). На практике — на моих mips(el) unaligned работает.
• sphinx_cv_interlocked (yes/no) — как раз издержки сборки под «legacy i386». Например, в optware для dd-wrt приходится ставить 'no', иначе сборка не удаётся. В более тюнингованной сборке openwrt тот же флажок можно не трогать; дефолтный 'yes' даёт вполне рабочий вариант. (Технические детали: в зависимости от флажка внутри используется либо атомарная lock-free операция __sync_fetch_and_add, либо структурка из переменной+мьютекса, которая делает ту же работу, но уже locked)
• ac_cv_c_bigendian (yes/no) — самая забавная из переменных. Если не публиковать индексы никуда «во внешний мир» — данную переменную можно проигнорировать. Как там у себя внутри демон хранит блобы — неважно; главное, чтобы правильно отвечал на запросы. А общение по сети, как положено, обставлено вызовами hton/ntoh и подобными, и потому влиянию endianess не подвержено. Однако как только вы попробуете, скажем, создать индекс на своём десктопе, а потом закинуть его в роутер «шоб работал» — тут-то и вылезают различия. Вкратце — загрузить индекс с другим endianess в настоящий момент НЕВОЗМОЖНО. В принципе, можно проблему и починить, но особого смысла в этом нет (покуда нет «огромной толпы пользователей», которые загружают индексы между платформами). Разницу между индексами легко увидеть, открыв файл .sph для просмотра (прямо дампом, F3 в mc). На индексе, созданном на платформе little-endian в заголовке вы увидите magic-подпись «SPHX». На big-endian — «XHPS».
  Узнать целевое правильное значение можно несколькими способами. Во-первых — уже упомянутый «научный тык». В сфинкс встроена runtime-проверка, которая при несовпадении фактических возможностей с заданными при компиляции вежливо выругается и подскажет правильное значение. Во-вторых, можно посмотреть харатеристики собранного бинаря с помощью команды file (неявно — нажав F3 на файле в mc на убунте). Увидав там «ELF 32-bit MSB executable» — понимаем, что имеем дело с big endian. А «ELF 32-bit LSB executable» говорит о little-endian. В этом случае вам повезло — можете создавать индексы на десктопе :). Наконец, третий и самый простой способ — посмотреть имя компилятора. 'mips' — это big-endian, 'mipsel' — little endian. Критическое значение правильный endianess имеет, если вы надумаете использовать лемматизатор aot (включается в конфиге как stemmer = lemmatize_aot_ru, lemmatize_aot_en, lemmatize_aot_de или всё вместе). Блобы словарей aot созданы на «обычном» PC c little-endian, поэтому на «вражеской» архитектуре требуют конвертации (которая осуществляется «на лету» прямо при загрузке, но для этого endianess должен быть правильно выставлен при конфигурации).
• ac_cv_func_realloc_0_nonnull=yes
• ac_cv_func_malloc_0_nonnull=yes — упомяну просто для полноты. «Бзик» автотулзов, в сфинксе никак не используются. Но без них сборка выдаёт ошибку, которая прямым гуглением приводит к такому решению-«затычке».

Да, кстати — упомянутые переменные (стиль именования, способ подсказывания «правильных ответов») — это, как вы поняли, не сугубая фича сфинкса, а свойство автотулзов. Ровно так же можно «подсказывать» ответы при конфигурации любого другого софта, написанного с использованием автотулзов.

Sphinx в optware

В папке целевой платформы (я собирал для ddwrt) перейдём в папку make и в ней скопируем template.mk в sphinxsearch.mk. Затем отредактируем полученную копию, руководствуясь инструкциями в самом файле. Это, собственно, и есть единственный необходимый (и зачастую достаточный) скрипт для добавления своего софта в optware. Вот ключевой кусок этого скрипта, который конфигурирует основную сборку:

(SPHINXSEARCH_BUILD_DIR)/.configured: sphinxsearch-source make/sphinxsearch.mk
	$(MAKE) libstdc++-stage
	$(MAKE) expat-stage
	$(MAKE) mysql5-stage
	rm -rf $(BUILD_DIR)/$(SPHINXSEARCH_DIR) $(@D)
	$(SPHINXSEARCH_UNZIP) $(DL_DIR)/$(SPHINXSEARCH_SOURCE) | tar -C $(BUILD_DIR) -xvf -
	$(LIBSTEMMER_UNZIP) $(DL_DIR)/$(LIBSTEMMER_SOURCE) | tar -C $(BUILD_DIR)/$(SPHINXSEARCH_DIR) -xvf -
	if test -n "$(SPHINXSEARCH_PATCHES)" ; \
		then cat $(SPHINXSEARCH_PATCHES) | \
		patch -d $(BUILD_DIR)/$(SPHINXSEARCH_DIR) -p0 ; \
	fi
	if test "$(BUILD_DIR)/$(SPHINXSEARCH_DIR)" != "$(@D)" ; \
		then mv $(BUILD_DIR)/$(SPHINXSEARCH_DIR) $(@D) ; \
	fi
	(cd $(@D); \
		export ac_cv_func_realloc_0_nonnull=yes; \
		export ac_cv_func_malloc_0_nonnull=yes; \
		export sphinx_cv_unaligned_ram_access=yes; \
		export ac_cv_c_bigendian=no; \
		export sphinx_cv_interlocked=no; \
		$(TARGET_CONFIGURE_OPTS) \
		CPPFLAGS="$(STAGING_CPPFLAGS) $(SPHINXSEARCH_CPPFLAGS)" \
		LDFLAGS="$(STAGING_LDFLAGS) $(SPHINXSEARCH_LDFLAGS)" \
		./configure \
		--build=$(GNU_HOST_NAME) \
		--host=$(GNU_TARGET_NAME) \
		--target=$(GNU_TARGET_NAME) \
		--prefix=/opt \
		--sysconfdir=/opt/etc/sphinxsearch \
		--with-libstemmer \
		--with-mysql=$(STAGING_PREFIX) \
		--without-unixodbc \
		--with-syslog \
		--enable-dl \
	)
	touch $@

Остальная часть сборки тривиальна (make, strip, упаковка). Кроме исходников сфинкса также требуются исходники libstemmer (будут утянуты при сборке прямо с их сайта). Также требуются собранные expat и mysql (покуда зависим от них; они будут собраны как зависимости). Помимо основного make-файла (лежащего в ./make) в структуре папок исходников optware также используется папка ./sources/sphinxsearch. В ней лежит init-скрипт для демона, который будет упакован в пакет и впоследствии при установке окажется в /opt/etc/init.d. Сборка осуществляется из корневой папки, при этом к имени пакета добавляются определённые суффиксы:

• make sphinxsearch — просто соберёт сфинкса в кросс-тулчайне. Полезно для отладки.
• make sphinxsearch-ipk — соберёт сфинкса, после чего создаст пакет .ipk
• make sphinxsearch-clean — убираем за собой мусор (после сборки).

В результате сборки c суффиксом -ipk мы получим «готовый к употреблению» пакет sphinxsearch.ipk, который установим в optware с помощью ipkg. Дальше всё как обычно — пишем конфиг, индексируем (а покуда для dd-wrt сборка по дефолту LSB — можно индексировать и на десктопе) — и взлетаем. Вуаля! При желании можно убрать зависимость от mysql (см. директиву SPHINXSEARCH_DEPENDS в полном конфиге) — покуда для запуска, собственно, демона эта библиотека не нужна (а если создавать индекс на стороне — то ВООБЩЕ не нужна на роутере). Возможно, понадобится чуть поправить переменные ac_cv_… и sphinx_cv_… В приведённом скрипте они поставлены исходя из сборки под optware для dd-wrt (а это архитектура mipsel, т.е. little-endian, и при этом максимально урезанный до legacy набор возможностей чипа)

Sphinx в openwrt

Если целевой openwrt на mips — запустить optware от ddwrt не удастся (там mipsel). Если же тоже на mipsel — можно запустить sphinx из optware, однако и в этом случае гораздо оправданнее в плане бережного использования ресурсов будет воспользоваться полной открытостью openwrt и сделать сборку именно под целевую систему — этим избавимся от ограничений legacy, а также получим более оптимальный код, который не будет грузить в память ещё один «чуть-чуть другой» экземпляр стандартной библиотеки.
Для сборки в openwrt также используются make-скрипты, только их формат и местоположение иные. Нужные файлы размещаются в отдельной папке, созданной где-нибудь в дереве package от корня сборочной среды. Например, я выбрал package/network/services/sphinx. В указанной папке минимально необходим файл Makefile, а также могут быть другие файлы и папки с предопределёнными именами. Я помимо Makefile использую ещё Config.in (он создаёт подменюшку в основном menuconfig), а также папку file/ где лежит образец конфига и init-скрипт (к слову, гораздо более короткий чем в optware). Ключевая часть конфигурации для openwrt выглядит вот так:

CONFIGURE_VARS += \
	ac_cv_func_realloc_0_nonnull=yes \
	ac_cv_func_malloc_0_nunnul=yes \
	ac_cv_c_bigendian=yes \
	sphinx_cv_unaligned_ram_access=yes

CONFIGURE_ARGS += \
	--prefix=/ \
	--sysconfdir=/etc/sphinx \
	$(if $(CONFIG_SPHINX_MYSQL_SUPPORT),--with-mysql,--without-mysql) \
	$(if $(CONFIG_SPHINX_PGSQL_SUPPORT),--with-pgsql,--without-pgsql) \
	$(if $(CONFIG_SPHINX_UNIXODBC_SUPPORT),--with-unixodbc,--without-unixodbc) \
	$(if $(CONFIG_SPHINX_EXPAT_SUPPORT),--with-libexpat,--without-libexpat) \
	$(if $(CONFIG_SPHINX_DYNAMIC_LOAD),--enable-dl,,) \
	--with-syslog \
	--with-libstemmer

Даже визуально она короче, чем в optware (сам скрипт целиком тоже существенно короче — всего 84 строки, бОльшая часть из которых — шаблонные). При этом задействованы переменные, которые конфигурируются из меню. В этой версии, возможно, потребуется подправить под свои нужны ac_cv_c_bigendian (я собирал под роутер NetGear WNDR4300, который MIPS, т.е. big-endian). Ещё в этой версии я не стал грузить при сборке отдельно libstemmer. Вместо этого его необходимо скачать заранее самостоятельно и запаковать в тарболл с исходниками (и поправить PKG_MD5SUM на ту, что будет у полученного тарболла).
Сборка пакета в openwrt осуществляется в два этапа. Во-первых, запускаем menuconfig в корневой папке и настраиваем прошивку в целом. Там НУЖНО зайти в раздел Network/Web Servers/Proxies — и уже там выбрать sphinx в виде модуля (M). Там же можно зайти в подменю конфигурации и поставить сборку с поддержкой нужных источников данных. Затем выходим из menuconfig, сохраняя изменения — и наконец, запускаем сборку всей прошивки:
make
либо только одного сфинкса (естественно, с зависимостями, если нужны)
make package/network/services/sphinx/compile
Полученные пакеты складываются в папку ./bin/ARCH/packages (в моём случае это ./bin/ar71xx/packages). Установить пакет можно либо прямо разыскав его и скопировав на роутер (а там натравив на него opkg), либо опубликовав сборочную папку на локальном веб-сервере и прописав путь к ней в /etc/opkg.conf на роутере, а затем — opkg update; opkg install sphinx.
Для индексации на роутере возможно отдельно понадобится установить клиентскую библиотеку mysql (я не стал прописывать её в зависимости установки в случае конфигурирования с динамической загрузкой нужных либ). И ещё — вручную создать для неё симлинк (командой ln -s libmysqlclient.so.16.0.0 libmysqlclient.so в папке где лежит либа). В остальном всё работает из коробки. Моё приложение использует сфинкс по протоколу sphinxql (т.е. та же libmysqlclient используется не только сфинксом для индексации mysql, но и клиентами для работы уже с самим сфинксом), однако legacy-протокол сфинкса (sphinx api, который всячески рекомендуется больше не трогать из клиентских приложений) также вполне функционален.

Напоследок — конфиги и скрипты.

Для optware:



Для openwrt:





Ну и пара готовых сборок.
sphinxsearch_2.2.2-4470-2_mipsel.ipk для optware в dd-wrt, платформа mipsel (LSB)
sphinx_2.2.2-2_ar71xx.ipk под openwrt на NetGear WNDR4300, платформа mips (MSB).