0

overview

The same dll(tableOcr.dll) in different system win10s(win10 family series and win10 professional series ) behave different result.

build tool

  1. java 
  2. corretto-1.8.0_302 
     openjdk version "1.8.0_302"
     OpenJDK Runtime Environment Corretto-8.302.08.1 (build 1.8.0_302-b08)
     OpenJDK 64-Bit Server VM Corretto-8.302.08.1 (build 25.302-b08, mixed mode)
  3. c++11
  4. visual studio 2017 (14.9)

background

I need java(x64) call my c++ func through jni, my shared library is tableOcr.dll(x64) and tableOcrJni.dll(x64) which links to tableOcr.dll; I did those steps:

  1. build my tableOcr.dll(x64) with visual studio 2017 (14.9), windows SDk version 10.0.17763.0 in win10 professional(x64 version=10.0.18363.1440) . TableOcrJNI.dll denpentent is tableOcr.dll,lickey_parse.dll and opencv_world430.dll(checked by x64 depend.exe) One of tableOcrJNI.dll function is :
#ifndef OCREXPORT
# if defined(_WIN32) || defined(__WIN32__) || defined(__CYGWIN__)
#   if defined(STATIC_LINKED)
#     define OCR_EXPORT
#   else
#     define OCR_EXPORT __declspec(dllexport) ///！ 为了动态加载动态库
//#     define OCR_EXPORT  ///！ 为了动态加载动态库
#   endif
# else
#   if defined(__GNUC__) && defined(GCC_HASCLASSVISIBILITY)
#     define OCR_EXPORT __attribute__ ((visibility("default")))
#   else
#     define OCR_EXPORT
#   endif
# endif
#endif

OCR_EXPORT int _cdecl obtain_table_info_init(const char* _IN_ models

  1. Use a test.exe(build on x64 professional win10) test win32 loadLibrary way to load tableOcrJni.dll. this dll loaded with absolute path.

    It success.

  2. Use java test program load my tableOcrJni.dll, it result in is not valid win32 IN windows 10 family series (x64 version=10.19043.1706)

addition

:

  1. I'm pretty sure %PATH% is OK for my java, I add my dlls(all linked dlls) path E:/mydll/ in It.
  2. I tried some solution found in google(included this palce), not helped.
  3. I tried step 3 in win10 professional(x64 version=10.0.18363.1440) series(), it is OK.
  4. I tried install vs 2017 on win10 family serial,and do step all failed.
  5. I tried build x64 corretto-1.8.0_302 jdk on x64 win10 family and do step3, failed.
ChuckiePan
  • 19
  • 5
  • 1
    DependencyWalker.com – Anders May 12 '22 at 14:12
  • 1
    It's unclear to me what errors or exceptions you are getting. Please include details like this in the body of the question. –  May 13 '22 at 14:32
  • @Anders I tried before I met this problem, DependencyWalker helped nothing, I checked the cpu type, checked deep linked libraries, all is fine. – ChuckiePan Jun 07 '22 at 00:59
  • @clvrmnky, sorry about that, the key is my dll cant run ok in win10 family series but win10 profissonal series – ChuckiePan Jun 07 '22 at 01:04

2 Answers2

0

It's a CPU architecture (bitness) mismatch between Java (the executable) and your .dll (pc064 <=> pc032 or viceversa). Check [SO]: Python Ctypes - loading dll throws OSError: [WinError 193] %1 is not a valid Win32 application (@CristiFati's answer) for more details on the topic.

To check Java architecture use:

[cfati@CFATI-5510-0:e:\Work\Dev\StackOverflow\q072210792]> java -version
java version "1.8.0_331"
Java(TM) SE Runtime Environment (build 1.8.0_331-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.331-b09, mixed mode)

In my case it's pc064 (064bit).

You have 2 options:

Since I don't know which is which, my advice is to move towards pc064.

In order to check PEs bitness, dependencies, and many more details, you could use [GitHub]: lucasg/Dependencies, or (older) Dependency Walker, or (VStudio's) DumpBin ([MS.Docs]: DUMPBIN Reference).

CristiFati
  • 38,250
  • 9
  • 50
  • 87
  • No, first doubt when I met this question is the mismatch. but I got wrong , I edited the question infomation. the question key is the same x64 dll loadlibrarys dirffent result – ChuckiePan Jun 07 '22 at 01:06
  • It's not easy for me to understand all the steps you did, but the error cause is the one that I explained. – CristiFati Jun 07 '22 at 01:59
  • Still kind of confusing to me (when I deal with this kinds of situations I change one thing at a time to isolate the problem sooner), but *java.exe* seems to be *032bit*. Or there are other *.dll*s with the same name and those get picked instead yours. – CristiFati Jun 07 '22 at 07:24
0

It is link styple mismatch. My tableOcrJni.dll behaves same as tableOcr.dll. So I just need try anything against tableOcr.dll. TableOcr.dll link some dlls like I said, So I put tableOcr.dll to E:/mydll, put tableOcr.dll's dynamic link dlls to E:/mydllDepend, activate ENV after that. It works in Win10 x64 family series !!!! but no prove has been found that I must do that way.

ChuckiePan
  • 19
  • 5