Исполняемый файл, который использует библиотеку lmdb, имеет формат 64-битной Linux.
Потому что библиотеки зависимостей исполняемого файла находятся в 64-битном. & lmdb lib как 32-битное решение невозможно.
Есть ли способ заставить 64-битную библиотеку lmdb сгенерировать 32-битную базу данных lmdb.
Мне нужен этот 32-битный файл базы данных, потому что сгенерированная БД будет экспортирована на 32-битное устройство.
Примечание: дБ, сгенерированный на 64-битной машине, не будет работать на 32-битной машине.
Я предполагаю, что использование 64-битной базы данных на 32-битной lmdb сложно, потому что lmdb основан на отображении памяти.
Таким образом, будет необходим конвертер, требующий понимания основного формата данных. Эта ссылка Формат файла LMDB кажется, хорошее начало для этого.
Дешевой альтернативой, похоже, является выгрузка файла на 64-битную платформу (mdb_dump
) и перезагрузить его на 32-битной платформе (mdb_load
). Тем не менее, это вызывает ограничения, как указано на связанной странице man:
Сброс и перезагрузка баз данных, использующих пользовательские функции сравнения, приведет к появлению новых баз данных, использующих функции сравнения по умолчанию. В этом случае вполне вероятно, что перезагруженная база данных будет повреждена и не подлежит восстановлению, что не позволит ни сохранить, ни восстановить записи.
Однако во время поиска в интернете я где-то читал, что это можно использовать для портирования 32-битной БД на 64-битную. Я могу только подозревать, что это должно работать противоположным образом (как я никогда не видел формат). Поскольку дамп представляет собой текстовый формат, это должно быть возможно — возможно, с промежуточным этапом обработки текста.
Другой, ИМХО довольно дешевый вариант, будет запуск 32-битного lmdb на 64-битной платформе. Поскольку я знаю, что это обычное явление для Windows, я не был (полностью) уверен в Linux и обнаружил следующее: SE: Как запустить 32-битное приложение в 64-битной Ubuntu?. К сожалению, спрашивающий заявил, что это не вариант в данном конкретном случае.
Других решений пока нет …