Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

amzijni.dll dependent libraries

Hi Dennis,
Retired some years ago, now getting back into it again (been a while since we chatted). Using Windows 10, have installed amzi_apls_win64_10-0-05 and eclipse neon, set directories and environment variables, according to instructions. Also added amzi jar file, and added the apls\bin folder, within eclipse. In trying to run the Hello.java file, got the following error:

Unable to load (lib)amzijni library: C:\amzi\apls\bin\amzijni.dll: Can't find dependent libraries

What to do? (Had actually begun revamping my old project, and got this error -- in netbeans, as well, and isolated it to constructing a new LogicServer, so tried the Hello project. Same problem.)
«1

Comments

  • Try setting the environment variable AMZI_DIR to point to your amzi/apls directory.
  • Had already set the variable to that directory (C:\amzi\apls). Still no dice.
  • Hmmm. Reading the message more carefully, Amzi! just spits back out the OS message, the problem appears to be the libraries that amzijni.dll uses. There is a free utility, dependency walker, that does what the name says it does. amzijni.dll, should be just dependent on amzi.dll and the kernal. Which makes me wonder if you can run the command line interpreter, say. Or if amzi.dll is in a different place from amzijni.dll? This seems unlikely to me.... Anyway, take a look at dependency walker and see if you can figure out what it's unable to find. --Dennis
  • Only today have had time to get back to this: ran dependency walker; there are 200+ files it could not find, even though I found a couple of them on my system (only tried half a dozen) -- but the others I tried, could not be found. All 'missing' files are either of the form API-MS-WIN-* or EXT-MS-*
    Some sample files that are 'missing':
    API-MS-WIN-CORE-APIQUERY-L1-1-0.DLL (found this in C:\$WINDOWS.~BT\Sources)
    API-MS-WIN-EVENTING-CONSUMER-L1-1-0.DLL (found this in C:\Windows.old\WINDOWS\WinSxS\x86_microsoft-windows-m..namespace-downlevel_31bf3856ad364e35_10.0.14393.0_none_42983f4d382b5cc7)

    API-MS-WIN-CORE-APPCOMPAT-L1-1-1.DLL
    API-MS-WIN-SECURITY-BASE-L1-2-0.DLL
    API-MS-WIN-DEVICES-QUERY-L1-1-1.DLL
    EXT-MS-WIN-CORE-WINRT-REMOTE-L1-1-0.DLL

    Again, am using Windows 10, 64-bit, if that matters. Never had this problem before; been using Amzi since '98.
  • Did Dependency Walker provide you with a tree of dependencies? These are from amzijni.dll, yes? amzi.dll doesn't have any problems? Are these all flowing from the JNI libraries? There are lots of Google places where people are getting errors with existing programs because of these missing files (seems they are Windows 8 files). I don't have Windows 10 installed, and went Open Source so I wouldn't have to. :-) You might have to rebuild that dll from the sources. I wonder if the issue is the JNI? amzijni.dll uses JNI, and it has all it's own dependencies. Best solution for me is for you to try to rebuild from the sources. You'll probably have to make modifcations to the build for the new environment, but shouldn't have to change any of the source code. --Dennis
  • Yes, there is a tree of dependencies; there are problems both with amzijni.dll and amzi.dll. Have looked more closely, and many (haven't checked all 200+) of the files are actually present somewhere on my computer, albeit with slightly different names (e.g., API-MS-*-L1-1-0.DLL is present, but ...L1-2-0.DLL is required. Some forums suggest that an internal renaming scheme should handle all this, but apparently that's not working. They also say that it shouldn't be necessary to download the files -- the old ones should work. Have put some folders containing some of these files onto my Path, and the number of 'missing files' decreases, but the remaining ones are scattered. Will take a while to see if this eventually resolves the issue. There must be a better way.

    For what it's worth, down the tree from amzi.dll, there are kernel32.dll, user32.dll, and advapi32.dll -- note that kernel32.dll also sits directly under amzijni.dll. Each of these shows multiple missing files, plus further nodes, which themselves have missing files (e.g., user32.dll has a node gdi32.dll, which is missing ~20 files).
  • Seems like a lot of the problems could be fixed by adding the directories onto the search PATH for the system, rather than moving the files. Can you get to it from Windows 10? It was always kind of hidden even on Windows 7.
  • That's what I spent a couple of hours yesterday doing -- the files are scattered hither and yon. Then realized that I couldn't find any of the 'EXT-MS' files anywhere on my computer (had been focusing on the 'API-MS' files). No idea where/how to get them, and even if I could, not convinced that would fix things.
    It just seems like the whole Windows/JNI system is a bit dodgy -- some Google sites saying that different versions of Windows (8, vs 8.1) require different JNI files. One might ask, why? Like I said, there must be a better way (not sure if it should be on the Windows or the Java side, or both). I just don't have enough experience with this stuff to know what will work.
  • 1- Can you run Amzi from the command line? Does alis work?
    2- I can walk you through the build process if you want to build a new amzijni for Windows 10, or is anyone else out there who does?
  • Yes, alis/command line works.
    I retired some years back, so it's just me, now. Am still intending to do some research from time to time, so would like to get amzi working. Would very much appreciate your help in this.
  • Well first step is to see if alis works from the command line. If so, then the problem is just with amzijni. The next step is to download the sources for amzijni and try to rebuild. It requires having Visual Studio. Hmmm, if you don't, that might be a show stopper.
  • Will see what I can do, re Visual Studio, and get back to you.
  • Apparently there is a free version of Visual Studio (Visual Studio Community) available to download (https://www.visualstudio.com/vs/community/). Would this do the job?
  • I don't know. All you can do is download the sources and try to run the builds. But, big question, can you run alis at the command line?
  • Yes, I can run alis from the command line.
  • OK, so then the problem is just with amzijni.dll, which is needed for interfaces with Java, and, hmmm, probably for running Eclipse. Which are you trying to do when you run into problems?
  • I'm wanting to run amzi from a java interface, eventually (it worked on my Windows7 machine, which died last year). But in Windows10, have tried to run (amzi) Hello.java from Eclipse and Netbeans; both fail. Figure that if we can get it working in Eclipse, I'll be good to go.
  • Right then, so amzi.dll is working, so all those dependencies are probably OK. Which means it's the thread down from the interface between amzi.dll and the jni that's causing the problem. So, to rebuild you need to download the sources from github (I'll point you there if you can't find it), install Visual Studio, and open up the amzijni project and try to rebuild it. You shouldn't need to change any of the sources, but the challenge will be getting all the libraries together that it needs to build. You'll need the latest Java SDK to get the JNI libraries to link with. (All the source code is in C++ for this, but, as I said, you don't need to change any of the source code, just the doo-dads for linking it all together.)
  • No doubt I'll have more questions later, but for now, suppose I rebuild the jni and get this all working on my computer, and eventually finish the project (a java interface running a prolog engine) I've been working on. I would then want to make it readily available to others. Would they then have to go through the same amzijni.dll-build process, in order to get it to work on their computers (particularly if they are running Windows10)?
  • Well no, that's the beauty of open source... You submit it as an update, and probably we would make it a separate build for Windows 10. The whole idea is to get me (71) out of ongoing development and put it in the hands of the users.
  • Have downloaded your AmziLS/interfaces -- is this the right source?
    Have java jdk1.8.0_101 installed already (the latest seems to be ...131) -- is 101 recent enough, or do I need to update?
    Will download and install Visual Studio (Community version) today.
    Is the 'project' you're referring to, the folder amzijni.xcodeproj? As I said, I have no experience with this stuff, whatsoever.
  • Great! Go to the interfaces/java/jnilib directory. There you'll find wjnilib.sln. That's the Visual Studio file for building amzijni.dll. You simply open wjnilib.sln and go to the build menu and select 'build solution' and it all will all magically work. OK, well it probably won't. The tedious part will be getting all the libraries right. You'll need to set an AMZI_DEV_DIR directory that points to your amzi/apls directory. Then, with the project open, right click on the project in the navigator panel on the left, and from the menu you see select 'properties' down at the bottom. That's where you'll be doing all your work. There's places to set include directories and libraries for the build. Edit those various fields as necessary. How to find what's necessary? Well start the build and you'll get errors that lead you on the path. Let me know if you get stuck on any errors, Good Luck and Thanks!
  • You're right -- no magic. Wanted Windows 8.1. Have retargeted solution, ran Build again, get error:
    Severity Code Description Project File Line Suppression State
    Error C1083 Cannot open include file: 'amzi.h': No such file or directory wjnilib d:\myprojects\amzi\interfaces-master\java\jnilib\amzijni.cpp 15
    I do see (in that folder) the amzijni.cpp file, but no 'amzi.h'.
  • The only 'h' files in that directory are amzijni.h and the LogicServer files.
  • AMZI_DEV_DIR should point to the amzi/apls directory. In that directory there should already be an 'include' directory. This should all be pointing to either the amzi distribution you downloaded, or that same thing in a different directory. The directory structure I use is:

    amzi
    release
    win64
    apls
    abin
    bin
    ...
    include
    ...
    source
    apls
    ide
    interfaces
    ...
    java

    The important bit is AMZI_DIR and AMZI_DEV_DIR both point to the release/win64/apls directory. From there the build will find the apls/include directory. In other words the build will build into the release directories.

    Now you might want to create a whole separate tree from this and use AMZI_DEV_DIR to point to the development tree, and AMZI_DIR your release one. But I think you can work with both the same like this.

    So the code under the release directory is the current binary distribution of amzi, which you have somewhere.

    Note, you don't have to use this tree structure, as long as AMZI_DIR and AMZI_DEV_DIR point to your distribution amzi/apls directory.
  • Right. Copied amzi.h from my amzi directory into the project directory (where I unzipped the Github download -- note that amzi.h is not in that repository).

    Reran Build, and got a new error, which I managed to fix (couldn't find jni.h) -- am apparently having to work on one error at a time. Will keep you posted.
  • Think I finally understood your previous comment, copied the Github download into 'new' source directory, and adjusted some variables in the Properties window; seems to have fixed the problems from before. Now getting 58 errors, all (all that I looked at, anyway) having to do with LogicServer. e.g.,

    Error LNK2019 unresolved external symbol _lsInitLSX@8 referenced in function _Java_amzi_ls_LogicServer_InitLSX@16 wjnilib C:\amzi\source\interfaces\java\jnilib\amzijni.obj Line 1

    No idea what to do about these.

    Also, getting a warning:
    Warning LNK4272 library machine type 'x64' conflicts with target machine type 'X86' wjnilib C:\amzi\apls\lib\amzi.lib Line 1

    Have tried changing variables in the Properties window, but nothing seems to work. My amzi release is the 64-bit version, and my machine/OS are 64-bit. Could it be that I downloaded the wrong Github stuff?
  • Fantastic! it's compiled, not linking. Those are all the entry points to amzi.dll, so it's not finding it, or rather the amzi.lib that describes it. It's in the distribution in the amzi/apls/lib directory. In the Linker section of the 'Properties' page under 'Input' you'll see a place for libraries. There it's asking for AMZI_DEV_DIR/lib, but if you're moving things into your directory, then you need to move amzi.lib there. Hmmm, reading more carefully, it looks like you're finding it but not linking... Do you have the active release (window at the top) set on the build for x64? The Visual Studio build can be used to build either the 32- or 64- bit versions. There's a box in the top that says which one. Yes, if you downloaded the 64-bit binaries you're just fine. The sources are the same no matter what platform you use. Hmmm, going on and on -- the amzi.lib file is from the distribution, the binaries for the 64-bit version. But the sources are not platform dependent.

  • seems I never posted that, rats...
  • You were right, had x86 set, changed it to x64 (had missed that wee window). Had to clear up a couple of other errors, and finally got it to Build -- the amzijni.dll file was created in the AMZI_DIR\apls\bin folder. There were several warnings (some deprecated bits, and some conversions), but the build succeeded.
    That's the good news.
    The bad news is that I still get the same error when I try to run (amzi) Hello.java (from eclipse):
    "Unable to load (lib)amzijni library: C:\amzi\apls\bin\amzijni.dll: Can't find dependent libraries"
    Seems like I'm right back where I started -- I even restarted Windows, and tried again, just in case. Ran Dependency Walker again, and it looks much the same as before.
    Any ideas?
Sign In or Register to comment.