La situation est que j'essaie de compiler netty-tcnative library version 2.0.3.Final sur un ordinateur Windows 10 32 bits. Je reçois l'erreur suivante:La compilation de netty-tcnative lié statiquement échoue avec incompatibilité avec jni.h à partir de JDK
[INFO] .\src\jnilib.c(360): error C2373: 'JNI_OnLoad': redefinition; different type modifiers [C:<redacted>\netty-tcnative\openssl-static\target\native-build\vs2010.vcxproj]
[INFO] C:\Program Files\Java\jdk1.8.0_131\include\jni.h(1945): note: see declaration of 'JNI_OnLoad'
[INFO] .\src\jnilib.c(423): error C2373: 'JNI_OnUnload': redefinition; different type modifiers [C:<redacted>\netty-tcnative\openssl-static\target\native-build\vs2010.vcxproj]
[INFO] C:\Program Files\Java\jdk1.8.0_131\include\jni.h(1948): note: see declaration of 'JNI_OnUnload'
J'ai ensuite comparé la signature de JNI_OnLoad et JNI_UnLoad dans jnilib.c de tcnative contre la jni.h du JDK.
jnilib.c
jint JNI_OnLoad(JavaVM* vm, void* reserved)
...
void JNI_OnUnload(JavaVM* vm, void* reserved)
jni.h
/* Defined by native libraries. */
JNIEXPORT jint JNICALL
JNI_OnLoad(JavaVM *vm, void *reserved);
JNIEXPORT void JNICALL
JNI_OnUnload(JavaVM *vm, void *reserved);
Je suis sur Java 8 131 mise à jour, mais j'ai vérifié cet en-tête de retourner à Java 7 et il est défini de la même façon. Il semble que le projet tcnative a modifié ce fichier lors de l'implémentation de la prise en charge de l'ombrage dans issue 272.
J'ai essayé de modifier le jnilib.c pour inclure les macros JNIEXPORT et JNICALL, mais il est remplacé par le processus de construction et quel que je voudrais avoir une accumulation répétitive qui ne nécessite pas de modifier les fichiers source. Qu'est-ce que je fais mal? Le même environnement de construction a pu générer la version 2.0.1.Final.
Si jnilib.c est écrasé par le processus de construction, alors vous devez modifier le code qui le génère, afin d'émettre des déclarations correctes. Vraisemblablement, le générateur de code actuel a été construit pour un système où les deux macros 'JNIEXPORT' et' JNICALL' se développent à néant, alors que ce n'est pas le cas sur Windows. –
@JohnBollinger C'est certainement une option. Ce même environnement (sur une VM) était capable de construire la version 2.0.1.Final de cette bibliothèque. Par conséquent, je sens que quelque chose a changé dans la bibliothèque et soit je ne suis pas au courant de la façon dont je suis supposé changer mon processus de construction, soit les responsables de la bibliothèque ont un bug. Je ne suis pas sûr de ce que c'est et j'espère que l'un des mainteneurs sonnera. – ZuluForce
Le problème est l'incohérence des déclarations multiples de vos deux fonctions. Une paire de déclarations provient de l'en-tête JNI externe, l'autre du code source généré. Puisque l'en-tête externe définit la signature et la convention attendues par l'implémentation JNI correspondante, la solution * seulement * raisonnable consiste à rendre le code généré cohérent avec l'en-tête JNI. Peut-être y a-t-il un moyen plus simple d'y parvenir que de pirater le générateur de code (consultez les docs), mais si vous êtes seulement intéressé par les commentaires des mainteneurs, allez sur un forum spécifique au projet. –