C++ dllexport/dllimport

**weaknessforcats** · Nov 16 '08, 12:27 AM

What does your DEF file look like?

Also, a DLL is a C structure. That means the function names have to be unique.

I assume all of the function names you have in the DEF file are all extern "C" in the C++ code.

The extern "C" also prevents your using member functions in the DEF file. You will need to write a wrapper for these.

**jjones7947** · Nov 17 '08, 12:15 PM

The .def file:

Code:

LIBRARY jsummarizer
EXPORTS
Java_com_sra_pipeline_servers_summarizer_JSummarizer_createSummarizer
Java_com_sra_pipeline_servers_summarizer_JSummarizer_setInOptions
Java_com_sra_pipeline_servers_summarizer_JSummarizer_setSentenceNum
Java_com_sra_pipeline_servers_summarizer_JSummarizer_setPhraseOpts
Java_com_sra_pipeline_servers_summarizer_JSummarizer_getSummary

As is shown in the listing above for the JNI implementation these are all "JNIEXPORT"
however a standard part of the javah generated header file is

Code:

#ifdef _cplusplus
extern "C" {
#endif

This fits inside the header guard statements/#def and the bracket encloses all the functions.
The functions that end up being unresolved symbols are not ones from my code. They exist in the API and they are exported or imported apparently at the time that the API DLL is compiled or not. Never seen this before, where the vender's compilation instruction force themselves into my compilation.
The only thing of concern from their code should be whether the function you want to use is exported, but then that's the whole point of a dll, their imports have never been an issue and are not in the C++ implimentation.

**weaknessforcats** · Nov 17 '08, 06:32 PM

If this is your DLL code:

Code:

#include <iostream>
using namespace std;

void __stdcall DisplayFromDll()
{
	cout << "This function was called from ADLL.dll" << endl;
}

int __stdcall AreaOfSquare (int len, int wid)
{
	return len * wid;
}

where __stdcall is WINAPI to Microsoft.

Then your DEF file looks like:

Code:

;BEGIN ADLL.DEF FILE
;This DEF file is required becuase the argument to GetProcAddress()
;for the function is a C-string and it will never be equal to the
;C++ mangled name for the function
;This DEF file maps the mangled name to a name that can be used with GetProcAddress()
;Note also: Change project settings in Visual Studio to send the LINK this def file.
;Visual Studio.NET: Project Properties/Linker/Input/Module Definition File/...Path to the def file\Adll.def
LIBRARY ADll 
EXPORTS 
;Exported Name    C++ Mangled Name
AreaOfSquare   =  ?AreaOfSquare@@YGHHH@Z
DisplayFromDll =  ?DisplayFromDll@@YGXXZ
;END DEF FILE

This code shows how to use the DLL:

Code:

#include <iostream>
using namespace std;

#include <windows.h>



int main()
{
	
	

	cout << "Calling functions from a dll" << endl;

	//First, load the dll into memory
	HMODULE theDll = LoadLibrary("C:\\Scratch\\ClassDemos\\ADll\\Debug\\ADll.dll");
	if (!theDll)
	{
		cout << "The dll failed to load" << endl;
		return 1;
	}

	//Second, get the address of the desried function from the dll
	FARPROC addr = GetProcAddress(theDll, "DisplayFromDll");
	if (!addr)
	{
		
		//Look up the error in the system errors list
		unsigned int what = GetLastError();
		if (what == ERROR_PROC_NOT_FOUND)
		{
			cout << "Function not found in the dll" << endl;
		}
		else
		{
			cout << "Error: " << what << endl;
		}
		return 2;
	}
    cout << "The function has been located in the dll" << endl;
	//Declare a function pointer that can accept the address of the function.
	//You will need to know the function prototype to do this.
	//Dll function prototypes should be provided by the vendor of the dll
	void (__stdcall *DisplayFromDll)();
	//Type-cast the address returned from GetProcAddress to the function pointer type
	DisplayFromDll = reinterpret_cast<void (__stdcall *)()>  (addr);
	//Now use the function pointer to call the function:
    DisplayFromDll();

	//If you don't use a .def file in the dll, you must use the mangled name
	//Second, get the address of the desried function from the dll
	addr = GetProcAddress(theDll, "AreaOfSquare");
	if (!addr)
	{
		
		//Look up the error in the system errors list
		unsigned int what = GetLastError();
		if (what == ERROR_PROC_NOT_FOUND)
		{
			cout << "Function not found in the dll" << endl;
		}
		else
		{
			cout << "Error: " << what << endl;
		}
		return 2;
	}

	cout << "The function has been located in the dll" << endl;
	//Declare a function pointer that can accept the address of the function.
	//You will need to know the function prototype to do this.
	//Dll function prototypes should be provided by the vendor of the dll
	int (__stdcall *AreaOfSquare)(int, int);
	//Type-cast the address returned from GetProcAddress to the function pointer type
	AreaOfSquare = reinterpret_cast<int (__stdcall*)(int,int)>  (addr);
	//Now use the function pointer to call the function:
    cout << "The area of a 6x8 square is " << AreaOfSquare(6,8) << endl;;

	//Finally, unload the dll from memory
	FreeLibrary(theDll);

	return 0;
}

Any C++ class code should be called from the API functions. Those LNK2019 and LNK2001 look like some of your code is not in your build, like maybe you are missing a library.

**jjones7947** · Nov 18 '08, 01:04 PM

Post Deleted by Poster

**jjones7947** · Nov 18 '08, 01:33 PM

First, some clarification. The .DEF file I posted is not the one for the vendor's dll, it is for the JNI dll which I can't get to build. This is my first time using MSVC for one of these projects, usually use GNI g++/gcc package. Using it I usually see in the build output a section where the C++ manged names are being resolved to the Java methods I tag with the qualifier "native" in the Java code and the JNI signatures.
The JNI file handles the Java - C/C++ interface and gives me a "native" environment to call native functions.
The loading and unloading that you talked about all happens on the Java side, I use System.loadLibr ary(<lib name>) to load the JNI dll, which has a dependency on the 3rd party dll and gets it loaded, but not directly as you showed. Unloading is handled implicitly or explicitly by Java's garbage collection. I will just need to clean up the 4 C++ objects I create.
Got to thinking about what you said, and made sure that I had all the paths to libraries. Added a couple but no luck.
Did however think about how the two projects are different. C++ built an exe mine builds a dll. In one of the vendor's .h files, specifically inxight-sum-declspec.h I found this song-and-dance:

Code:

// -*- C++ -*- Copyright (C) 2002 Inxight Software Inc.  All Rights Reserved.
#ifndef INXIGHT_SUM_DECLSPEC
#define INXIGHT_SUM_DECLSPEC

// If we're compiling using the MSVC++ compiler, use declspec(dll[im|ex]port)
// to control interface objects that are exported from the DLL.
#if defined(_MSC_VER) && !defined(INXIGHT_BUILDING_SUMMARIZER_TEST)
# ifdef INXIGHT_BUILDING_SUMMARIZER_DLL
#  define INXIGHT_SUMMARIZER_EXPORT __declspec(dllexport)
# else
#  define INXIGHT_SUMMARIZER_EXPORT __declspec(dllimport)
# endif
#else
# define INXIGHT_SUMMARIZER_EXPORT
#endif


#endif

In the C++ project, I was actually working under their test project so INXIGHT_BUILDIN G_SUMMARIZER_TE ST would have been defined so it would fail through at that point. On the dll project it would pass the first line and because I'm not building the Summarizer dll (Summarizer37.d ll) it falls into the first # else. This certainly matches the value of INXIGHT_SUMMARI ZER_EXPORT that is showing up in the errors.
Now my understanding is that this is happening because I am building against the .lib files. My info is that when you do that you are actually pulling the vendor's functionality into your dll, which makes their preprocessor directives in scope. Does that make sense? This is the first time I've had .libs available, normally I build against the dll. Will try building it that way.
BTW looked up your profile. Your an inspiration to me, to still be actively involved in this field at your age is commendable, born in 46 here our generation continues to make contributions, and I my feeling is we're better off for staying involved. Thanks
Jim

**jjones7947** · Nov 18 '08, 02:30 PM

Tried it with only the primary DLL i.e. Summarizer37.dl l and all the errors went away. Unfortunately, I now have a LNK1136 error "invalid or corrupt file" have tried all the remedies MS advocates, any ideas?
Jim

**jjones7947** · Nov 18 '08, 03:24 PM

Apparently linker.exe does not link against a dll, and that is source of the LNK1136 error. Finally got it to work. Was including too many .lib files in the project. I included only summarizer.lib and platform37.lib and it compiled. When I put the dll in my Java project and tried to call it I got an error. At least I have the command line to use in my ant script so will keep at it.
Thanks very much
Jim

**weaknessforcats** · Nov 18 '08, 05:08 PM

[quote=jjones794 7]
Did however think about how the two projects are different. C++ built an exe mine builds a dll.
[/code]

What does that mean??

C++ does not build an exe. Are you referring to MSVC? If so, and it is building a exe, you have the wrong project type. Am I just hallucinating here?

**jjones7947** · Nov 18 '08, 08:13 PM

Yes using MSVC, and the C++ project was mostly to ensure that I could hang on to the 4 setup objects (summarizer, inputopts, sentenceopts, and phraseopts) and have them available and valid when I called the final constructor for summarization. In that sense it was successful. So I didn't try the next step of building a dll with the C++ code which I guess would make it an extension of the vendor's library. Instead I skipped to compiling the JNI code into a dll, which is where I had the problem. But did get it to build finally.
When I called it from Java I could call the function that creates the summarizer object, the one that creates the input_options object, the sentence-options and the phrase_options; with no problems. It fails when I try to pass all those objects + the byte stream to the constructor for summarization. My print statements show me that it never gets past that step.
This does indicate that the Java code is communicating with the JNI which in turn is communicating with the vendor's dll. According to the error file that Java generates the Problematic frame is in kernel32.dll + 0x12a5b.
I've asserted the pointers to the first 5 objects and they pass, but I realized that only meant they had been assigned, and not much else. They surely point to an address, but I don't know how to determine whether that address still holds the value I placed there.
If I place a "DeBug()" statement before that problem line and look at the objects in VC7 debug, it appears they are all valid, in that they have addresses.
The stak from the Java error file is:
Stack: [0x003a0000,0x00 3f0000), sp=0x003ef2e4, free space=316k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [kernel32.dll+0x 12a5b]
C [summarizer37.dl l+0x1e583]
C [summarizer37.dl l+0x17e14]
C [summarizer37.dl l+0x15c55]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j com.sra.pipelin e.servers.summa rizer.JSummariz er.getSummary(L java/lang/String;)Ljava/lang/String;+0
j com.sra.pipelin e.servers.summa rizer.JSummariz er.doSummarizat ion(Ljava/lang/String;)V+10
j com.sra.pipelin e.servers.summa rizer.JSummariz er.main([Ljava/lang/String;)V+58
v ~StubRoutines:: call_stub
I've been in this place before I went off to try the VC7 projects, and don't know where to go from here.
Jim

C++ dllexport/dllimport

C++ dllexport/dllimport

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment