Мне нужно создать DLL, которая затем может быть загружена с помощью JNI из Java-программы. Я смог сделать это в прошлом году, и это работало нормально. Я пытаюсь перекомпилировать мой тот же файл .cpp сейчас, хотя я делаю DLL с, и он терпит неудачу из-за включенной зависимости DLL, которая вводится.
У меня есть программа на С ++, которая вызывает около 5 функций из некоторого существующего кода на С ++. Эти функции являются частью огромной кодовой базы, которые обычно все связаны друг с другом, чтобы создать набор из 5 библиотек.
Я использую средство обхода зависимостей для просмотра моей dll, и в прошлом году она была скомпилирована с двумя зависимыми системными dll, помещенными в мою dll. Сегодня я пытаюсь перекомпилировать ту же самую DLL, но она приносит третий файл DLL, если я связываюсь с файлом .lib из нашей существующей кодовой базы, которая содержит функции, которые я использую.
По сути, я знаю, что моя dll будет хорошо работать с JNI, если я смогу избежать появления третьей dll в моей программе. Проблема в том, что я не знаю, как ссылаться на нужные мне функции в моем коде из нашей существующей кодовой базы без ссылки на файл lib.
Я могу заставить это работать со стандартными файлами и методами c ++. Эта проблема возникает только тогда, когда я ссылаюсь на этот ранее существующий код из нашей огромной базы кода.
Если я не связываю свой файл .obj с файлом .lib из нашего кода, я получаю неразрешенные справочные сообщения от моего компилятора Borland 5.5, который я должен использовать.
Общая проблема заключается в том, что мой dll-файл работает нормально, когда я вызываю его из exe-файла c ++, но Java не может что-то обработать в нем. Кроме того, если я скомпилирую свой код в файл .so в Unix вместо Windows DLL, Java JNI работает нормально и может загрузить его. Я знаю, что проблема связана с тем, как Windows использует dll, и я знаю, если этот 3-й dll не загружается как часть моей dll, он также будет работать. Я просто понятия не имею, что я сделал в прошлом году, чтобы построить свой dll без этого третьего, показанного как зависимость.
Если я закомментирую функции из нашего существующего кода, он прекрасно компилируется и загружается, потому что 3-я зависимость от dll не помещается в мою dll.
Подробнее
У меня было сообщение об отсутствии _strcopy, поэтому я связался в файле cw32mti.lib, и это ушло, но затем этот файл cw32mti.dll появляется в моем файле dll. Как я могу предотвратить пропущенное ссылочное сообщение для чего-то подобного и не допустить того, чтобы он поместил dll в мою dll?
Моя команда ссылки выглядит следующим образом.
ilink32 mydll.obj, mydll.dll ,, cw32mti
Единственный способ получить другие недостающие ссылки для работы - это добавить другую dll в мою команду ссылки, например:
ilink32 mydll.obj, mydll.dll ,, cw32mti.lib other.lib
Где other.dll содержит функции, которые я вызываю из mydll.dll, например, Calculate (int a, int b), поэтому в моем коде есть ссылка, подобная Calculate (num1, num2); Проблема в том, что когда я использую библиотеку, которая содержит метод Calculate, он также вводит другие библиотеки DLL, связанные с other.dll, которые я не хочу загружать. Мне нужно иметь возможность вызывать вычисления (num1, num2) без добавления other.dll в mydll.dll. Раньше это работало без динамического вызова метода расчета и использования типа кодирования getprocaddress.
Обновление - мне в конечном итоге пришлось отказаться от того, чтобы заставить Windows DLL работать с менеджером памяти smartheap. Поскольку этот код был развернут в Unix, я смог просто собрать файлы .so и заставить их работать с JNI. Для компиляции Windows dll я поместил некоторые условные операторы компилятора вокруг кода JNI, который вызывал загрузку smartheap dll, поэтому, когда он компилируется в Windows, он не использует этот код. Вместо этого я просто распечатал заявление о том, что он не выполняется в Windows.
Мы также столкнулись с проблемами позже, когда наш 64-битный сервер JBoss запустился и загрузил эти 32-битные файлы .so. В итоге я запустил параллельный сервер JBoss рядом с 64-битным и вызвал методы, которые ссылались на 32-битную библиотеку на 32-битном экземпляре JBoss.
Это может перерасти в более позднее, но сейчас эта задача работает для нас после месяцев попыток многих разных вещей.Я ценю всю помощь и вклад здесь.