Чем больше я об этом думаю, тем больше это похоже на [Википедия]: XY проблема .
1. X (запуск файла MEX на компьютере без библиотек MATLAB )
Согласно [MathWorks]: Запустите MEX-файл, который вы получили от кого-то другого ( подчеркивания мои):
На платформах Windows® установите библиотеки времени выполнения компилятора C ++, используемые для создания файла MEX .
...
MEX-файл - это динамически связанная подпрограмма , которую интерпретатор MATLAB загружает и выполняет при вызове функции. Динамическое связывание означает, что когда вы вызываете функцию, программа ищет зависимые библиотеки. В файлах MEX используются библиотеки времени выполнения MATLAB и языковые библиотеки. MEX-файл может также использовать специализированные библиотеки времени выполнения. Код для этих библиотек не включен в файл MEX; библиотеки должны присутствовать на вашем компьютере при запуске файла MEX .
[MathWorks]: MATLAB Runtime содержит ссылки для загрузки многих версий ( ваша - в соответствии с вашими путями - будет [MathWorks]: MCR Runtime - MCR_R2012a_win32_installer.exe ), которые бесплатны (я установил 3 из этих версий для тестирования этого сценария), а также заявляет:
Запуск скомпилированных приложений или компонентов MATLAB без установки MATLAB
Итак, для меня совершенно очевидно, что тот, кто хотел бы использовать этот файл, должен установить MCR .
2. Y (с использованием Delay Loaded DLL s)
VStudio поддерживает эту функцию ( [MS.Docs]: поддержка компоновщика DLL-библиотек с задержкой ) в течение достаточно долгого времени.
Никогда не работал с MEX файлами, и при этом у меня нет полной спецификации проблемы, но я разрешил запуск одного такого файла при отсутствии MATLAB .dll Это не похоже на хороший дизайн для меня (это означает, что он также содержит другие вещи - которые, по моему мнению, должны быть размещены отдельно). Единственный сценарий, который имеет смысл, состоит в том, что файл MEX будет .exe (не знаю, возможно ли это, или это просто глупость), и он будет иметь некоторые --help эквивалент (что было бы неплохо (но , а не обязательно) для запуска в средах без .dll ).
Но это также можно решить другими способами (например, README как файл)
3. Конечная проблема
Учитывая, что в вопросе было / есть несколько (логических) ошибок:
- .dll s переданы компоновщику
- Файлы .lib , расположенные в bin dir
- Последний путь ( extern / lib / win64 / microsoft ) содержит 64 бит .lib с, в то время как компоновщик установлен на 32 бит выход
- [MS.Docs]: Ошибка инструментов компоновщика LNK1107 , что довольно ясно (как сообщение об ошибке в вопросе)
Я могу только заключить, что для Release , " C: \ Program Files (x86) \ MATLAB \ R2012a \ bin \ win32 \ libmx. dll " был неправильно передан компоновщику (вместо соответствующего .lib ).
Я немного поиграл с MEX :
code.c
#include <stdio.h>
#include <conio.h>
#include <mex.h>
int main(int argc, char **argv) {
if (argc > 1) {
fprintf(stdout, "Argument passed: mexEvalString() returns\n", mexEvalString("n = 1;"));
} else {
fprintf(stdout, "Argument NOT passed: pass...\n");
}
fprintf(stdout, "Press a key to exit...\n");
_getch();
return 0;
}
Примечания
Я использовал fprintf , потому что в mex.h есть строка:
#define printf mexPrintf
Не знал, какую функцию использовать из libmx.dll , чтобы принудительно добавить ее (не только зависимость для libmex.dll )
- Мне удалось протестировать функцию DLL с задержкой в Отладка и Release (при отсутствии аргумента программа работала без добавление MEX .dll s к % PATH% ).
Это правда, что во время выполнения я получил Нарушение доступа , но это совсем другая проблема
- Нет необходимости говорить, что добавление любого из .dll s к " Linker -> Input -> Additional Dependencies ", вызвало точно такую же ошибку
В заключение хотелось бы отметить, что MCR R2012a (и некоторые другие, выпущенные после него), построены с VStudio 9.0 (2008) , и сборка вашей программы с помощью VStudio 10.0 (2010) приведет к загрузке обоих процессов CRT Lib , а в некоторых случаях это может вызвать некоторые ошибки (особенно если VStudio 9.0 поставляется как сборка ).
Это относится к libmx.dll и libmex.dll , но не libeng.dll .