Попробуем организовать эмулятор для ARMv7 при помощи QEMU 4.20 и установим какой-нибудь Linux.

Для начала нам понадобится скачать так называемый netboot образ системы для armhf, состоящий из двух компонент: vmlinuz и initrd.gz. После ряда экспериментов выяснилось, что современные инсталляторы Ubuntu по умолчанию непригодны для этих целей, так что возьмем Debian Buster[1].

Подготовим файл образа “диска”, в который будем устанавливать систему:

qemu-img create -f qcow2 debian.qcow2 8G

В ряде инструкций рекомендуется подготовить сеть, подняв на хост-машине tap-интерфейс, что позволит иметь возможность достучаться с хост-машины в гостевую, но для упрощения ситуации запустим сеть в usermode – она работает достаточно быстро и для ряда задач её хватит.

Собираем файлы в одном месте и запускаем эмулятор со следующими параметрами:

qemu-system-arm -smp 4 -m 1024 -M virt \
   -kernel vmlinuz \
   -initrd initrd.gz \
   -append "root=/dev/ram" \
   -netdev user,id=n1
   -device virtio-net-device,netdev=n1 \
   -drive if=none,file=debian.img,format=qcow2,id=hd \
   -device virtio-blk-device,drive=hd \
   -no-reboot

Параметры:

• smp – количество ядер;
• m – объем памяти;
• M – тип машины, virt – абстрактно-виртуальный ARM;
• netdev – тип сети, user – самый простой вариант, не требующий настройки хост-машины;
• device virtio-net-device – устройство “сетевой карты”, и выбирать следует именно это, а не упомянутое в различных инструкциях, т.к. иначе с огромной вероятностью вы наткнетесь на сообщение о том, что инсталлятор системы не обнаружил никаких сетевых устройств в системе;
• drive if=none,file=debian.img,format=qcow2 – образ жесткого диска;
• device virtio-blk-device – устройство “жесткого диска”, аналогично сети, этот вариант обнаруживается установщиком, многие другие – нет;
• no-reboot – перезапуск системы приведет к остановке эмулятора.

Если запускаем qemu-system-arm в консоли без графического интерфейса, то дописываем “-nographic”.

Устанавливаем Debian как обычно. На количестве ядер не следует экономить, т.к. в процессе установки есть этапы, которые, по всей видимости, могут неплохо параллелиться, а однопоточная производительность эмулятора далека от производительности хост-машины: в среднем на установку системы уходило около часа на четырехъядерном Intel Xeon 3.5 GHz.

Ближе к концу установки инсталлятор ругнется на невозможность установки grub – так и должно быть в этом эмуляторе.

Далее, когда инсталлятор сообщит о завершении, выберите “Go back” и из главного меню установщика выберите пункт про вход в консоль. В консоли целевой диск, куда производилась установка, будет доступен по пути /target. Поскольку у эмулятора нет загрузчика, нам понадобится вытащить уже из установленной системы соответствующие ей vmlinuz и initrd.img. Для этого можно сделать chroot /target и, используя набор стандартных утилит – например, scp – откопировать файлы, находящиеся в /target/boot (а после chroot так просто в /boot) куда-нибудь вовне эмулятора. Если установленных утилит не хватает, то уже в chroot-е можно легко использовать apt и apt-get для установки недостающего. После копирования выходим из консоли и в меню инсталлятора выбираем пункт завершения установки. Когда установщик выполнит перезагрузку, эмулятор просто выключится согласно опции no-reboot.

Конечно, в качестве альтернативы можно вынуть vmlinuz и initrd из установленной системы и при помощи средств конвертации и распаковки qcow2 файлов – таких инструкций в интернете уйма. В этом случае прежде, чем что-то сделать с образом диска, не забывайте остановить эмулятор, чтобы не повредить образ.

Причина же, по которой изначально не удалось использовать современные образы Ubuntu, состоит в том, что в них после установки по малопонятной причине не генерируется файл initrd.img – в директории /target/boot есть битые симлинки на него, тогда как сам initrd отсутствует. [Update: Способ исправления был найден в комментариях на gist.github.com[2]]

Итак, после описанных действий у вас должен оказаться на руках образ debian.img с установленной ОС и файлы vmlinuz и initrd.img, взятые из этого же образа. Старые vmlinuz и initrd.gz с netboot-инсталлятором можно удалить – они больше не понадобятся. Теперь для запуска системы нужно переписать аргументы qemu-system-arm на следующие:

qemu-system-arm -smp 4 -m 1024 -M virt \
   -kernel vmlinuz \
   -initrd initrd.img \
   -append "root=/dev/vda2" \
   -netdev user,id=n1
   -device virtio-net-device,netdev=n1 \
   -drive if=none,file=debian.img,format=qcow2,id=hd \
   -device virtio-blk-device,drive=hd \
   -no-reboot

Вот, в общем-то, и всё.

Для того, чтобы зайти извне в такую гостевую машину по SSH, можно заменить -netdev user,id=n1 на -netdev user,hostfwd=tcp::10022-:22,id=n1, и тогда при подключении к порту 10022 на хост-машине соединение будет перенаправлено на 22 порт гостевой машины. Либо воспользоваться ssh-туннелем, подняв из гостевой машины подключение к удаленному ssh-серверу с дополнительным параметром -R 10022:localhost:22 – в этом случае порт 10022 на удаленном сервере будет перенаправлен на порт 22 гостевой машины.

Теперь можно пробовать собирать программы нативным компилятором нужной архитектуры, а не кросс-компиляцией. Ну или зачем там вы ещё запускали этот эмулятор.

После изучения означенного вопроса оказалось, что суть проблемы сводится к битриксовому API CIBlockElement::GetList() и соответствующему ему GetNext(), которые при некоторых условиях переставали высвобождать память после каждого своего вызова. Очевидно, что после попытки выполнения их по нескольку десятков тысяч раз внутри одного скрипта (который по расписанию перегенерирует карту сайта), разрешенный объем памяти в PHP довольно быстро заканчивался.

Тот факт, что ранее тот же самый код работал без подобных проблем, со временем вывел расследование на opcache, а конкретно – к оптимизации ZEND_OPTIMIZER_PASS_6 (1<<5) /* DFA based optimization */. По счастью, настройки opcache позволяют выбирать активные оптимизации и отключать те, что могут вызывать проблемы. Соответственно, в конфигурацию была добавлена следующая опция, отключающая только проблемную оптимизацию и оставляющая все остальные:

opcache.optimization_level=0x7FFEBFDF

Понятно, что это могло привести к какой-то деградации производительности в opcache, но при выполнении означенных ранее циклов полностью перестала утекать память.

Для справки, полный список опциональных оптимизаций:

#define ZEND_OPTIMIZER_PASS_1		(1<<0)   /* CSE, STRING construction     */
#define ZEND_OPTIMIZER_PASS_2		(1<<1)   /* Constant conversion and jumps */
#define ZEND_OPTIMIZER_PASS_3		(1<<2)   /* ++, +=, series of jumps      */
#define ZEND_OPTIMIZER_PASS_4		(1<<3)   /* INIT_FCALL_BY_NAME -> DO_FCALL */
#define ZEND_OPTIMIZER_PASS_5		(1<<4)   /* CFG based optimization       */
#define ZEND_OPTIMIZER_PASS_6		(1<<5)   /* DFA based optimization       */
#define ZEND_OPTIMIZER_PASS_7		(1<<6)   /* CALL GRAPH optimization      */
#define ZEND_OPTIMIZER_PASS_8		(1<<7)   /* SCCP (constant propagation)  */
#define ZEND_OPTIMIZER_PASS_9		(1<<8)   /* TMP VAR usage                */
#define ZEND_OPTIMIZER_PASS_10		(1<<9)   /* NOP removal                 */
#define ZEND_OPTIMIZER_PASS_11		(1<<10)  /* Merge equal constants       */
#define ZEND_OPTIMIZER_PASS_12		(1<<11)  /* Adjust used stack           */
#define ZEND_OPTIMIZER_PASS_13		(1<<12)  /* Remove unused variables     */
#define ZEND_OPTIMIZER_PASS_14		(1<<13)  /* DCE (dead code elimination) */
#define ZEND_OPTIMIZER_PASS_15		(1<<14)  /* (unsafe) Collect constants */
#define ZEND_OPTIMIZER_PASS_16		(1<<15)  /* Inline functions */

#define ZEND_OPTIMIZER_IGNORE_OVERLOADING	(1<<16)  /* (unsafe) Ignore possibility of operator overloading */

PS: Всё это не было бы особо мозголомно, если бы не тот факт, что вся эта проблема наблюдалась на одном сайте и не наблюдалась на другом – в разных пулах PHP-FPM в рамках одного и того же сервера. Объяснение тому оказалось прямолинейным: там, где проблема не наблюдалась, opcache отчего-то не функционировал. Нет, не был выключен в настройках – он был включен, но просто перестал работать. После перезапуска FPM проблема начала одинаково воспроизводиться на обоих сайтах. Впоследствии, к слову, это же вынудило переустановить PHP из репозитория Remi, раз в официальном и версия PHP получала лишь обновления безопасности к старому релизу, а не обновления к более новым, и происходили подобные вещи. К сожалению, начальную проблему с DFA это обновление не исправило.

Наглядный пример – RHEL8. Для чистого iptables и аналогов есть модули nf_conntrack_helper и, в частности, nf_conntrack_ftp. Интернет подсказывает, что в ядрах версии 4.7 и выше они по умолчанию отключены и требуют или ручного включения, или отдельной маркировки соединений. Но вот только у RHEL8 предлагается использовать надстройку FirewallD, мануал которого ещё в 2016 году упоминал автоматическое использование соответствующего helper-а, если в конфигурации файрвола активирован стандартный сервис ftp, открывающий доступ к 21-му порту. Так, утверждается, что в выбранном по умолчанию режиме AutomaticHelpers = system должно проверяться значение /proc/sys/net/netfilter/nf_conntrack_helper (которое в >4.7 выключено) и, в зависимости от него, будут предприниматься необходимые меры для автоматического открывания портов для передачи данных через FTP. Но проблема в том, что этого не происходит.

Практический же опыт показывает, что помимо активации в файрволе сервиса ftp всё же необходимо в firewalld.conf дописать AutomaticHelpers = on, после чего никаких отдельных настроек портов для passive mode FTP не понадобится. Отчего это не работает в режиме system в релизной версии RHEL8 – неизвестно.

Вот только при запуске успешно собранного бинарника можно увидеть ошибку pdns_server: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.26′ not found (required by pdns_server)

Она говорит о том, что указанная библиотека ни черта не прилинковалась статически.

Заставить ее это сделать можно дописыванием LDFLAGS перед запуском ./configure:

LDFLAGS="-static-libstdc++" ./configure --with-modules="gmysql" --without-lua --enable-static --enable-static-boost --prefix=/

Это отвяжет зависимость от версии libstdc++ на целевой машине.

Говорят, для другого софта может пригодиться вбивание -static-libgcc, если он собирается CC, а общий -static попытается собрать всё остальное статически.

А так-то понятно, что лучше не собирать на коленке вручную, а использовать готовые пакеты требуемого софта для имеющейся операционной системы. Когда они есть в природе. Правда ведь, RHEL8?

Наличие root-доступа предоставляет возможность немного поиграться с системой. Например, по умолчанию на каждое конкретное действие робот отвечает одной единственной фразой. И хорошо, если не по-китайски. Не очень весело, правда?

Попробуем сделать так, чтобы вместо этого робот отвечал случайной репликой из соответствующей категории фраз. Для этих целей будет использоваться самописная пользовательская файловая система fuse, сделанная на базе bbfs. Смысл состоит в том, чтобы при обращении к какому-либо файлу со звуком – например, sound.wav – модифицированная ФС проверяла наличие рядом файлов с именами sound_1.wav, sound_2.wav и т.д. и случайно выбирала один из них. Все прочие же действия bbfs просто пробрасывает в нижележащую файловую систему без изменений.

Ручная установка

Инструкция далее предполагает минимальное умение пользоваться linux-терминалом через putty и (win)scp, а так же уже рутированное ПО на роботе. Если это не для вас – смело пропускайте этот раздел и переходите ниже.

1. Сначала установим нужную локализацию, на базе которой будет строиться наша – например, при помощи WIN-MIROBO. В результате на роботе по пути /mnt/data/rockrobo/sounds появится каталог с набором звуковых wav-файлов.
2. Делаем копию этого каталога в соседний, например: /mnt/data/rockrobo/sounds_multi, не забываем сделать chown на ruby (или другого пользователя, не root) как каталога sounds, так и sounds_multi (для удобной заливки новых wav-файлов через winscp).
3. Установим поддержку файловых систем fuse, используя стандартные пакеты к Ubuntu 14.04 для armhf: понадобятся libfuse2_2.9.2-4ubuntu4.14.04.1_armhf.deb и fuse_2.9.2-4ubuntu4.14.04.1_armhf.deb с launchpad.net. Для установки забрасываем файлы в робота и используем dpkg -i имя_файла.
4. Забрасываем в робота собранный бинарник файловой системы bbfs и кладем его, к примеру, в /usr/local/bin, делаем его запускаемым (chmod +x)
5. В файле /etc/fuse.conf раскомментируем опцию user_allow_other, т.к. в противном случае из-под root-а не будут видны файлы в смонтированных пользователем каталогах, делаем этот файл читаемым для всех (chmod +r).

Теперь мы готовы запустить bbfs. Для этого заходим из-под ruby (или другого пользователя, главное – не root) и набираем следующую команду: bbfs -o nonempty,allow_root /mnt/data/rockrobo/sounds_multi /mnt/data/rockrobo/sounds. После этого в каталоге sounds будут показаны все файлы из sounds_multi, но при выборе основного файла sounds/sound.wav в действительности будет запрошен случайным образом либо sounds_multi/sound_N.wav, либо исходный sounds_multi/sound.wav.

Отметим, что N ∈ [1;20] – и только в порядке возрастания (т.о. если файла sound_1.wav нет, то sound_2.wav даже проверяться не будет).

Для размонтирования обратно используем команду fusermount -u /mnt/data/rockrobo/sounds, и в /mnt/data/rockrobo/sounds возвращается его исходное содержимое.

Если вручную все завелось корректно, то для автоматического старта при запуске робота можно добавить в /etc/rc.local следующую строку: su ruby -c "bbfs -o nonempty,allow_root /mnt/data/rockrobo/sounds_multi /mnt/data/rockrobo/sounds". Не забываем указывать правильного пользователя после su и не теряем кавычки.

Предсобранные прошивки

На сайте github.com/rand256 есть предсобранные прошивки с рут-доступом, Valetudo RE и предустановленной в том числе и системой рандомизации фраз. После установки такой прошивки необходимо только создать на роботе директории /mnt/data/rockrobo/sounds и /mnt/data/rockrobo/sounds_multi и положить в последнюю набор файлов озвучки, включающих разные перефразированные реплики под каждое событие: например, start.wav, start_1.wav, start_2.wav.

Таким образом, после перезагрузки робот станет использовать для одного и того же события разнообразные слова вместо постоянного повторения единственной фразы – и это звучит намного живее и естественнее.

Заведение IP:

ifconfig eth0:1 <ip-address> netmask <netmask> up

Если это роутер с NAT или просто нужна возможность организовать внешние соединения с этого IP (а не на него), то требуется новая таблица в /etc/iproute2/rt_tables. Далее:

ip route add <network>/29 dev eth0:1 src <ip-address> table <table>
ip route add default via <network gateway> table <table>
ip route add 192.168.0.0/24 dev eth1 table <table>
ip rule add from <network> table <table>

Посмотреть, что получилось:

ip rule show
ip route list table <table>

Задать маршруты по умолчанию тем же ip route, но без table. Правила iptables для NAT типовые.

Если удобоваримый результат достигнут, далее можно искать специфичные скрипты того или иного дистрибутива для менее варварской настройки. Если их нет, то rc.local.

Симптомы: на виндовых машинах подключение к VPN виснет на “проверке имени пользователя и пароля”, затем выдается ошибка 619. В логах PPTP-сервера видно, что он не получает отклика от клиента и сбрасывает подключение по таймауту, а в трафике видны только исходящие GRE-пакеты в сторону PPTP-клиента. На NAT-шлюзе в трафике при этом присутствуют и входящие, и исходящие GRE-запросы.

Спустя время было выявлено, что затык именно на стороне клиента, а именно на NAT-шлюзе: для работы PPTP на нем нужно подгрузить следующие модули (для CentOS):

modprobe ip_nat_pptp
modprobe ip_conntrack_pptp
modprobe ip_gre

Несмотря на то, что, казалось бы, каких-либо открываний портов, или разрешений протоколов в файрволе, или других настроек на NAT-шлюзе для использования на стоящих за ним компьютерах PPTP-клиента не требуется, все-таки кое-что сделать придется. Так как с настройками по умолчанию (по крайней мере, для CentOS 6) GRE-трафик пропускаться не будет.

Хотя relay-функциональность icecast и позволяет разбирать этот код и реагировать на него соответствующим образом, работает это не всегда.

Можно столкнуться со следующей ситуацией: головной source-сервер перегружен и выдает редиректы на дополнительные серверы, при проверке браузером все корректно, но наш icecast-ретранслятор их будто “не замечает” и выдает клиентам ошибку 404. В логах нашего icecast’а при этом можно увидеть следующие записи:

[2015-09-25  10:58:40] INFO slave/start_relay_stream Starting relayed source at mountpoint "/<mountname>"
[2015-09-25  10:58:40] INFO slave/open_relay_connection connecting to <main.source>:80
[2015-09-25  10:58:40] INFO slave/open_relay_connection redirect received HTTP://<fallback.source>

После этого клиенту выдается ошибка 404 и более ничего содержательного в лог не попадает. Так в чем же дело?

В исходном коде icecast можно найти следующие строки:

            ICECAST_LOG_INFO("redirect received %s", uri);
            if (strncmp (uri, "http://", 7) != 0)
                break;

Так выясняется, что если полученная ссылка из 302-го редиректа не начинается на “http://” (в НИЖНЕМ регистре!), то наш icecast с ней не будет делать вообще ничего и сделает вид, что никакого редиректа не было. А как видно из лога, наш источник рассылает редиректы, начинающиеся на HTTP:// в верхнем регистре.

Очевидно, надо научить icecast не обращать внимание на разницу регистров в протоколе. Это можно сделать разными способами, оптимальность и красота которых зависит от качества вашего владения кунг-фу Си. Можно, например, сделать как-то так:

--- icecast-2.4.2/src/slave.c   2015-04-08 11:06:13.000000000 +0300
+++ icecast-2.4.2-mod/src/slave.c       2015-09-25 10:55:29.495738535 +0300
@@ -238,13 +238,19 @@
         if (strcmp (httpp_getvar (parser, HTTPP_VAR_ERROR_CODE), "302") == 0)
         {
             /* better retry the connection again but with different details */
-            const char *uri, *mountpoint;
-            int len;
+            const char *uri, *mountpoint, *proc = "http://";
+            int i, len;

             uri = httpp_getvar (parser, "location");
+
             ICECAST_LOG_INFO("redirect received %s", uri);
-            if (strncmp (uri, "http://", 7) != 0)
-                break;
+            for (i = 0; i < 7 && uri[i]; i++) {
+                if ((tolower(uri[i]) - tolower(proc[i])) != 0) {
+                    i = 10;
+                    break;
+                }
+            }
+            if (i == 10) break;
             uri += 7;
             mountpoint = strchr (uri, '/');
             free (mount);

Пересобираем, подключаемся, смотрим лог:

[2015-09-25  11:08:40] INFO slave/start_relay_stream Starting relayed source at mountpoint "/<mountname>"
[2015-09-25  11:08:40] INFO slave/open_relay_connection connecting to <main.source>:80
[2015-09-25  11:08:40] INFO slave/open_relay_connection redirect received HTTP://<fallback.source>
[2015-09-25  11:08:40] INFO slave/open_relay_connection connecting to <fallback.source>:80
[2015-09-25  11:08:40] WARN format/format_get_type Unsupported or legacy stream type: "audio/mpeg". Falling back to generic minimal handler for best effort.
[2015-09-25  11:08:40] INFO source/source_main listener count on /<mountname> now 1

И все работает.

Может возникнуть закономерный вопрос: зачем изобретать велосипед и почему бы не использовать обычный rsync для копирования данных напрямую в davfs2? Ответ простой: это… не работает как надо. Во всяком случае, с Яндекс.Диском, и если запускать процедуру на роутере под управлением OpenWrt.

То ли из-за особой неторопливости Яндекс.Диска, то ли из-за особенностей davfs2, но при попытке копирования большого количества файлов (а иногда такое случается и с единичными файлами!), большая их часть оказывалась в каталоге lost+found, служащем для локальных копий файлов, загрузка которых в WebDav провалилась. И всё это несмотря на достаточный объем выделенного кэша, стандартные настройки davfs2 для повторной загрузки файлов в случае ее неудачи, и довольно широкого канала связи.

Итак, для самописного и более надежного бэкапера в WebDav нам понадобятся:

1. davfs2 – стандартный пакет из репозитория OpenWrt;
2. cadaver – модифицированная версия утилиты для прямого копирования файлов в WebDav из нашего архива;
3. php-cli – стандартный интерпретатор PHP, при помощи которого мы сгенерируем набор команд для cadaver’а.

Добавленные в cadaver патчи позволяют при помощи нового ключа -F пропускать проверку подлинности сертификатов (а под OpenWrt у нас все используемые в WebDav SSL-сертификаты считаются подозрительными и требуют ручного подтверждения), а также указывать с помощью ключа -n нестандартный путь к хранилищу паролей для автоматической авторизации на WebDav-сервере. Внесенные изменения позволяют создать для cadaver файл с набором команд, которые будут выполняться автоматически без участия человека.

Теперь обратим внимание на скрипт phpsync.php.

У этого скрипта две задачи:
Во-первых, он отвечает за “обратную синхронизацию” – в скрипте производится проверка, все ли находящиеся в WebDav-хранилище файлы продолжают находиться на локальном диске. В случае обнаружения в удаленном хранилище файлов, которые были локально удалены, скрипт удалит их и из WebDav – обычным вызовом unlink() на смонтированном разделе davfs2.
Во-вторых, скрипт генерирует набор команд для cadaver‘а для загрузки локально измененных или отсутствующих в WebDav файлов в удаленное хранилище.
В скрипте есть ряд параметров, которые нужно настроить. Так, параметром $outfile определяется путь к файлу, в который будет записан сгенерированный набор команд, в параметре $remotebase необходимо указать точку монтирования davfs2. Также в нем указывается адрес WebDav сервера, к которому должен подключаться cadaver – по умолчанию это https://webdav.yandex.ru. Затем следует указать каталоги, которые требуется синхронизировать, например:

phpsync("/srv/content","/backup/content");
phpsync("/srv/otherdir","/backup/otherdir");

Так будут сгенерирован набор команд для отражения локальных каталогов /srv/content и /srv/otherdir в удаленные WebDav-каталоги /backup/content и /backup/otherdir соответственно. Обратите внимание – удаленные пути указываются относительно корня WebDav-диска, без привязки к локальной точке монтирования davfs2!

После этого следует создать парольный файл для cadaver. Это обычный текстовый документ, содержающий строку следующего вида:

machine webdav.yandex.ru login вашлогин password вашпароль

Наконец, создаем ash-скрипт, который мы будем вызывать через кронтаб:

#!/bin/ash
/usr/bin/php-cgi -f /srv/phpsync.php

if [ -e "/var/.phpsync.list" -a $(wc -l "/var/.phpsync.list" | awk '{print $1;}') -gt 2 ]
then
        /usr/bin/cadaver -F -r "/var/.phpsync.list" -n "/srv/auth.rc"
fi

Подставляем ваши значения:

• /srv/phpsync.php — путь к PHP-скрипту;
• /srv/auth.rc — путь к парольному файлу;
• /var/.phpsync.list — путь к файлу с набором команд для cadaver.

Не забываем сделать скрипт исполняемым, выполнив команду chmod +x на данном файле. Теперь мы можем проверить работоспособность копирования, запустив этот скрипт. В терминал при этом будет выведен результат работы PHP-генератора, а также будет показан процесс выполнения задания cadaver’ом.

Если все завершилось успешно – теперь можем добавить автоматический вызов данного скрипта через кронтаб в ночное время и более не беспокоиться о создании резервных копий.

Давным-давно, в далекой-далекой галактике… оказалось, что много лет назад некий товарищ по имени ioannis в рамках решения означенной проблемы создал небольшое расширение SQLite, по сути представляющее собой урезанную версию ICU, из которой был выброшен код, который в 95% случаев никогда не потребуется. Таким образом удалось сократить размер расширения с мегабайт до символических 70-90 кбайт (в зависимости от архитектуры и компилятора). Копия исходного сообщения осталась доступна на mail-archive.com, и хотя оригинальная ссылка на исходный код расширения sqlite3_unicode.c неработоспособна, его все еще можно найти в интернете, а также мы добавили его в наш архив.

Возможности расширения

#define SQLITE3_UNICODE_FOLD – поддержка нелатинских символов функцией FOLD() – +10КБ
#define SQLITE3_UNICODE_LOWER – поддержка нелатинских символов функцией LOWER() – +10КБ
#define SQLITE3_UNICODE_UPPER – поддержка нелатинских символов функцией UPPER() – +10КБ
#define SQLITE3_UNICODE_TITLE – поддержка нелатинских символов функцией TITLE() – +10КБ
#define SQLITE3_UNICODE_UNACC – преобразование accented-символов в обычные, для русского языка не очень актуально – +30КБ
#define SQLITE3_UNICODE_COLLATE – заменяет COLLATION типа NOCASE на новый, в котором при сравнении не учитывается регистр в т.ч. и для нелатинских символов.
#define SQLITE3_UNICODE_UNACC_AUTOMATIC – попытаться применять UNACC в функции LIKE и операциях сравнения с COLLATE NOCASE.

Что характерно, функциональность, которая не требуется, может быть отключена путем убирания соответствующих #define для экономии места и увеличения производительности (вряд ли, впрочем, существенного).

Теперь разберемся, как собрать это расширение и задействовать его в cli-версии SQLite и в модуле для PHP.

Сборка под Linux

Для начала, скачиваем и распаковываем исходный код SQLite – нам потребуются заголовочные файлы из него. Можно использовать любую версию: я брал amalgamation без autoconf – она меньше. В тот же каталог копируем sqlite3_unicode.c.

Далее, корректности ради, открываем sqlite3_unicode.c текстовым редактором и вписываем вверху директиву:

/* we want shared library. only. */
#define SQLITE_ENABLE_UNICODE 1

Этим мы указываем, что собираемся компилировать shared-библиотеку. С другой стороны – соответствующий #if в коде расширения написан таким своеобразным образом, что этого можно и не делать.

Затем следует непосредственно процесс компиляции. Предполагается, что пакеты из набора build-essentials уже установлены в системе – во всяком случае, здесь потребуется gcc:

gcc -shared -o sqlite3_unicode.so sqlite3_unicode.c

Закрывая глаза на ряд warning’ов, получаем готовую библиотеку.

При работе с cli-версией потребуется разместить полученный sqlite3_unicode.so в каталоге с остальными системными библиотеками, либо же выполнить export следующего вида:

export LD_LIBRARY_PATH="/path/to/library/dir:$LD_LIBRARY_PATH"

Затем открываем cli и пишем команду .load sqlite3_unicode. Если ошибок не возникло – значит, расширение успешно загрузилось.

Для загрузки расширения в PHP потребуется в php.ini выставить корректный путь к месту расположения библиотеки в перараметре sqlite3.extension_dir. Затем в скрипте используем команду вида $db->loadExtension(‘sqlite3_unicode.so’);

Вот и всё – теперь сравнения с COLLATE NOCASE будут регистронезависимыми не только для латиницы, но и для русских букв.

Сборка под OpenWrt

Теперь попробуем побороть Buildroot от OpenWrt и кросс-компилировать это расширение в toolchain’е для запуска на роутере. В конечном счете, именно ради этого весь процесс и затевался – на ПК-то нет проблемы установить ICU, в отличие от встраиваемых систем. Надо признать, что борьба с Buildroot’ом для меня оказалась намного сложнее, чем все поиски решения проблемы с регистрозависимостью в целом и попытки разобраться, как его собирать в обычных условиях, в частности.

В конечном счете, после бессчетных неудачных попыток, я остановился на варианте формирования отдельного пакета, содержащего только это расширение с выставленным параметром DEPENDS на libsqlite3 и включенным в его состав С-файле с исходным кодом. Скачать готовый пакет можно в нашем архиве.

Его можно распаковать в каталог “package” корневой директории Buildroot’а, а затем нужно в make menuconfig выбрать пакет libsqlite3_unicode и запустить его сборку при помощи команды make package/libsqlite3_unicode/compile.

После установки полученного ipk на роутер подключение данного расширения производится аналогичным ранее описанному способом. Обратите внимание, что имя расширения для OpenWrt – libsqlite3_unicode.so, его размещение по умолчанию – /usr/lib.