Ответ 1
Одно из решений заключается в том, чтобы изменить способ, которым матлаб открывает ваш плагин, написав небольшой файл-загрузчик mex, который сам не имеет зависимости от boost, назовите его foo.mexglx
Это вызов mexFunction просто делает это
void mexFunction (int nlhs, mxArray * plhs[], int nrhs, mxArray * prhs[])
{
gMexEntry (nlhs, plhs, nrhs, prhs);
}
где переменная gMexEntry является указателем функции, объявленным как
typedef void (*entryfunc_t)(int, mxArray**, int, const mxArray**);
entryfunc_t gMexEntry;
и заполняется статическим конструктором при загрузке модуля (вся проверка ошибок игнорируется для краткости).
fh = dlopen ('bar.mexglx', RTLD_NOW | RTLD_DEEPBIND );
void * p = dlsym (fh, "mexFunction");
gMexEntry = reinterpret_cast<entryfunc_t> (p);
Цепочка событий заключается в том, что, когда Matlab называет вашу функцию, тонкая оболочка без зависимостей boost будет открывать вашу функцию с помощью зависимости boost, используя параметр RTLD_DEEPBIND dlopen, который поместит область поиска символов в этой библиотеке (с использованием вашей версии boost) перед глобальной областью (с использованием старого повышения Matlab). Затем фактический вызов mexFunction будет перенаправлен на бар.
Если вы правильно установили ссылку на cmdline, используя "ldd", вы должны увидеть, что "foo.mexglx" не имеет зависимости от boost, а "bar.mexglx" имеет все ваши обычные зависимости.
Я использую эту технику в течение многих месяцев без очевидных признаков отказа. У меня все еще есть некоторые опасения, что то, что я не понимаю, может пойти не так, но пока это единственное решение, которое у меня есть (кроме написания полного механизма выполнения вне процесса, реплицирующего интерфейс mxArray и общаться с трубами или связывать все статически, что не подходит для моей ситуации)