Подвержены ли Native Interface (JNI) проблемы совместимости C ++ ABI?
Подвержены ли Native Interface (JNI) проблемам совместимости C ++ ABI?
Я разрабатываю приложение Java. Я хотел бы использовать собственный интерфейс Java (JNI) для вызова функций в библиотеке C ++. У меня есть доступ к коду библиотеки C ++, и я могу перестроить его, как бы мне ни потребовалось. (Например, я могу статически связать среду выполнения C ++.)
Я могу потребовать от моих пользователей иметь JRE 6 или выше, но я не могу требовать от них наличия какой-либо конкретной среды выполнения C ++.
Сотрудник указал мне на эту статью в блоге: http://www.trilithium.com/johan/2005/06/static-libstdc/ , в которой не рекомендуется использовать динамически загружаемый код C ++.
Другой коллега указал мне на этот отчет об ошибке: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4694590 , в котором подробно описано, как эти проблемы были решены в Java 1.4.2. .
Суть проблемы, насколько я понимаю, в том, что бинарный интерфейс libstdc ++ часто меняется. Если приложение C ++ загружает общую библиотеку C ++, созданную с помощью другого компилятора, две несовместимые библиотеки libstdc ++ будут загружены в память одновременно.
В отчете об ошибке объясняется решение для Java 1.4.2: «Мы статически связываем среду выполнения C ++ в JDK и включили скрипт компоновщика для скрытия символов из libstdc ++ и других внутренних символов. В результате эти символы становятся невидимыми для кода JNI, и когда некоторый собственный код должен вызвать среду выполнения C ++, вызов будет разрешен с помощью соответствующей библиотеки libstdc ++. итак. Есть еще две библиотеки libstdc ++., поэтому загружаются одновременно, но это должно быть безопасным. "
У меня есть несколько вопросов по этому поводу.
Во-первых, продолжает ли OpenJDK придерживаться этого подхода?
[ РЕДАКТИРОВАТЬ: Я задал этот вопрос в списке рассылки OpenJDK build-dev. Ответ - да, HotSpot по-прежнему статически связывает libstdc ++, но, очевидно, «большинство дистрибутивов Linux исправляют это».Другой разработчик отмечает, что для этого даже не требуется патч: «Настройка STATIC_CXX = false должно быть достаточно (по умолчанию true). "]
Во-вторых, даже в этом случае, действительно ли допустимо иметь два несовместимых libstdc ++. Загруженных одновременно?
В-третьих, подходит ли это для (чтобы скрыть символы в JDK) решить все проблемы совместимости?
В упомянутой выше статье блога предупреждается, что «код, скомпилированный для разных ABI, просто несовместим с двоичными кодами». И позже, «поддержка языковой среды выполнения обычно полагается о некоторых данных, например для доступа к какой-то блокировке или глобальной структуре данных (аналогично тому, как программам на C требуется общий номер ошибки). "
Это звучит так, будто проблема не может быть решена.
Опять же, возможно, несовместимость ABI не является проблемой Проблема больше. Этой статье в блоге больше шести лет. Один ответ на другой вопрос о переполнении стека ( Совместимость с GCC ABI ) утверждает, что «Начиная с gcc-3.4.0, ABI поддерживает прямую совместимость». Было ли это успешным ?
Буду признателен за любые рекомендации по этим вопросам (и, эй, спасибо, что прочитали все это!)
РЕДАКТИРОВАНИЕ
Мой вопрос становился довольно длинным, поэтому я не стал вдаваться в подробности. Чтобы ответить на комментарии Уилла:
- Мне нужно только вызвать функции extern "C". (Например, я использую javah для создания файла заголовка C.)
- Мне не нужно взаимодействовать со средой выполнения C ++ в среде выполнения. JVM. (Мне просто нужно отправить строки в библиотеку C ++.)