Получение «Java Result: -1073741571» при загрузке библиотеки Cryptopp

Это выглядит странно для меня, но я не эксперт JNI на любом участке:

public static void main(String[] args){
    System.loadLibrary("cryptopp");
    System.loadLibrary("ZCPP_Code64");
}

Я бы ожидал увидеть что-то вроде (от одного из моих проектов Crypto++/Android/JNI):

public class PRNG {

    static {
        System.loadLibrary("stlport_shared");
        System.loadLibrary("cryptopp");
        System.loadLibrary("prng");
    }

    private static native int CryptoPP_Reseed(byte[] bytes);

    private static native int CryptoPP_GetBytes(byte[] bytes);

    private static Object lock = new Object();

    // Returns the number of bytes consumed.
    public static int Reseed(byte[] seed) {
        synchronized (lock) {
            return CryptoPP_Reseed(seed);
        }
    }

    // Returns the number of bytes generated.
    public static int GetBytes(byte[] bytes) {
        synchronized (lock) {
            return CryptoPP_GetBytes(bytes);
        }
    }
}

Не беспокойтесь о stlport_shared потому что это Android-приложение.

---

Это также выглядит странно:

#pragma comment(lib, "cryptlib.lib")
//#pragma comment(lib, "crypt32.lib")
#pragma comment(lib, "cryptopp.lib")

Поскольку вы вызываете System.loadLibrary("cryptopp"), это означает, что вы используете DLL Crypto++. Это также означает, что это не нужно: #pragma comment(lib, "cryptlib.lib"). Выберите статическое связывание или динамическое связывание, но не оба.

Вероятно, было бы проще, если бы вы (1) построили вашу DLL ZCPP_Code64 и (2) статически связаны с Crypto++. Тогда ваш статический загрузчик будет выглядеть так:

    static {
        System.loadLibrary("ZCPP_Code64");
    }

---

Если вы выберете статическое соединение с Crypto++, вам, вероятно, придется перестроить статический lib. Это потому, что вы попадете в эту конфигурацию:

Your DLL -> dynamic linking against the C Runtime
Crypto++ LIB -> static linking against the C Runtime

Это вызовет кучу повторяющихся символов (C Runtime symbols). Вы хотите:

Your DLL -> dynamic linking against the C Runtime
Crypto++ LIB -> dynamic linking against the C Runtime

Чтобы исправить это, вы открываете проект Cryptlib и изменяете объект привязки Runtime от статического до динамического. См. "Статическое сравнение с динамическим связыванием" при компиляции и интеграции Crypto++ в среду Microsoft Visual C++.

---

Это выглядит хорошо для меня:

JNIEXPORT void JNICALL Java_ru_zontwelg_Loader_loadCache 
(JNIEnv *env, jobject jobj)
{
    ...
}

Что я не уверен... где родные библиотеки должны быть расположены в Windows. Для этого взгляните на Java JNI и зависимые библиотеки в Windows.

---

Вам также придется выполнять блокировку, если несколько потоков обращаются к одному и тому же базовому объекту Crypto++. В моем случае основным объектом был AutoSeededRandomPool:

public class PRNG {

    ...

    // Returns the number of bytes consumed.
    public static int Reseed(byte[] seed) {
        synchronized (lock) {
            return CryptoPP_Reseed(seed);
        }
    }

    // Returns the number of bytes generated.
    public static int GetBytes(byte[] bytes) {
        synchronized (lock) {
            return CryptoPP_GetBytes(bytes);
        }
    }
}

В вашем случае это может быть Base64Encoder или Base64Decoder.

Помните, что все объекты класса Crypto++ являются потокобезопасными, потому что они не имеют доступа к глобальным или общим данным. Но они небезопасны, когда несколько потоков (mis) используют один и тот же объект.

---

Книга, в которой я консультируюсь по вопросам JNI, - это интерфейс Java Native Interface: Руководство программиста и спецификация.

---

Наконец, жаль насчет "ответа". Это не ответ. Скорее, это большой комментарий, который не вписывался бы в блок комментариев.