1
votes

I need to build a DLL that can then be loaded with JNI from a java program. I was able to do this last year and it worked fine. I'm trying to recompile my same .cpp file now though that I make the dll with and it is failing because of an included dll dependency that gets brought in.

I have a c++ program that calls about 5 functions from some existing C++ code here. These functions are part of a huge codebase that are normally all linked together to build a set of 5 dlls.

I use dependency walker to view my dll and last year it compiled with just 2 dependent system dlls being put in my dll. Today I'm trying to recompile the same dll, but it brings in a 3rd dll file if I link with the .lib file from our existing codebase that contains the functions I use.

Basically I know my dll will work fine with JNI if I can avoid that 3rd dll showing up in my program. The problem is I don't know how to reference the functions I need in my code from our existing code base without linking to the lib file.

I can get this to work with standard c++ files and methods. This problem only happens when I reference this preexisting code from our huge codebase.

If I do not link my .obj file with a .lib file from our code I get unresolved reference messages from my Borland 5.5 compiler I have to use.

The overall issue is that my dll file works fine when I call it from a c++ exe file, but Java cannot handle something in it. Also, if I compile my code into a .so file in unix instead of a windows dll, Java JNI works fine and can load it. I know the problem is related to how Windows uses dlls, and I know if this 3rd dll doesn't load as part of my dll it will also work. I just have no idea what I did last year to build my dll without this 3rd one showing as a dependency.

If I comment out the functions from our existing code it compiles fine and loads because the 3rd dll dependency doesn't get put in my dll.


More Details

I had a message about missing _strcopy, so I linked in the cw32mti.lib file and that went away, but then that cw32mti.dll shows up in my dll file. How do I prevent the missing reference message for something like that and prevent it from putting the dll in my dll?

My link command looks like this. ilink32 mydll.obj, mydll.dll,,cw32mti

The only way I get the other missing references to work is adding the other dll to my link command like: ilink32 mydll.obj, mydll.dll,,cw32mti.lib other.lib

Where other.dll contains functions I call from mydll.dll such as calculate(int a, int b), so my code has a link it in like calculate(num1, num2); The problem is when I use the lib that contains the calculate method, it also brings in other dlls linked to the other.dll that I do not want to load. I need to be able to call calculate(num1, num2) without adding other.dll to mydll.dll. This worked before without dynamically calling calculate and using the getprocaddress type of coding.


Update - I eventually had to give up on getting the windows dll to work with the smartheap memory manager. Since this code was deployed in unix, I was able to just build the .so files and get those to work with JNI. For the Windows dll compile, I put some conditional compiler statements around the JNI code that was causing the smartheap dll to be loaded, so then when it compiles in windows it does not use that code. Instead I just had it print out a statement saying it was not executing in windows.

We also ran into issues later with getting our 64 bit JBoss server to run and load these 32 bit .so files. I ended up running a parallel JBoss server next to the 64bit one and called the methods that referenced the 32 bit library on the 32 bit instance of JBoss.

It may evolve into more later, but for now this task is working for us after months of trying many different things. I appreciate all of the help and input here.

1

1 Answers

0
votes

If you can get your hands on the application DLL built from last year, use TDUMP to see what the module dependencies are. (You might have to analyze all the DLLs to get a good picture.) Then endeavor to reproduce that in the new DLL, probably by adjusting the linker's configuration .DEF file.

Without any code or .DEF file shown in your question, it is very difficult to be more specific.