How to Access a C++ lib that is linked into a Fortran dll from C#

[onkelhotte]

Hi,

this one sounds more complicated then it is.

I have a C++ lib that is linked into a Fortran dll. Now I want to access some functions of this C++ lib from a C# program. But the program doesn´t find the entry point. Calling Fortran routines is no problem.

Could it be that I can just call the C++ lib from the Fortran dll and not from a program that uses that dll?

Thanks in advance,
Markus

[IanH]

Are the C++ library routines exported from the DLL?  If not, then you need to do that.

[onkelhotte]

Not yet :-)

So, I have to write an interface and an DLLEXPORT in these interfaces?

[IanH · Accepted solution]

You basically need to tell the linker when it creates the DLL the names of the C++ functions that need to be exported.  There are at least three ways of doing this (similar to the three ways that exist for Fortran exports):

- You put some magic declaration stuff in the C++ code that tells the compiler that the function is to be exported - with MS C++ you put __declspec(dllexport) in the function prefix.  This is the equivalent of !DEC$ DLLEXPORT in ifort.  The compiler will flag the procedure in the resulting object file so the linker exports it.

- you supply the linker with a module definition file (.def) that tells it the linker symbol for each function to be exported in an EXPORTS section.

- you tell the linker the symbols of the functions to be exported on the command line using the /EXPORT linker command line option.

For C++ code with C++ linkage (stuff not declared extern "C") the linker symbol for the function is mangled brutally from the actual in-source fucction name in order to implement C++'s ability to override functions.  That means that the first option is probably best.  Otherwise you can use the dumpbin utility on the C++ library to see what the symbol is for a particular function.

[onkelhotte]

Thanks, I´ll modify and test my code.

[FortranFan]

IanH wrote:

That means that the first option is probably best (i.e., - You put some magic declaration stuff in the C++ code that tells the compiler that the function is to be exported - with MS C++ you put __declspec(dllexport) in the function prefix).

If the code is going to be used in multiple applications and by multiple users over a period of time (i.e., multiple revisions may come into play), then consider the module definition file option.  That is my scenario usually and hence I prefer the .def files.  A side benefit is the code doesn't become ugly with all the export specifications thrown in its midst which may need to be tweaked or further modified with preprocessor macros if one moved to another compiler.

Here's a link to Microsoft's MSDN site that explains the export function options:

• Visual Studio 2013
• Visual Studio 2012
• Visual Studio 2010
• Visual Studio 2008
• Visual Studio .NET 2003

To determine which method to use to export functions (a .def file or the __declspec(dllexport) keyword), answer the following questions:

• Will you be continuing to add additional exported functions?

• Who is using your DLL? For example, is it a third-party DLL used by many executables that you cannot rebuild or is the DLL used only by applications that you can easily rebuild?

Pros and Cons of Using .DEF Files

Exporting functions in a .def file gives you control over what the export ordinals are. When you add additional exported functions to your DLL, you can assign them higher ordinal values (higher than any other exported function). When you do this, applications using implicit linking do not have to relink with the new import library that contains the new functions. This is very important, for example, if you are designing a third-party DLL for use by many applications. You can continue to enhance your DLL by adding additional functionality while at the same time ensuring that existing applications continue to work properly with the new DLL. The MFC DLLs are built using .def files.

Another advantage to using a .def file is that you can export functions using the NONAME attribute, which places only the ordinal in the exports table in the DLL. For DLLs with a large number of exported functions, using the NONAME attribute can reduce the size of the DLL file. For information about writing a module definition statement, see Rules for Module-Definition Statements. For more information about ordinal export, see Exporting Functions from a DLL by Ordinal Rather Than by Name.

The major disadvantage of using .a def file is that if you are exporting functions in a C++ file, you either have to place the decorated names in the .def file or define your exported functions with standard C linkage by using extern "C" to avoid the name decoration done by the compiler.

If you need to place the decorated names in the .def file, you can obtain them by using the DUMPBIN tool or by using the linker /MAP option. Note that the decorated names produced by the compiler are compiler specific. If you place the decorated names produced by the Visual C++ compiler into a .def file, applications that link to your DLL must also be built using the same version of Visual C++ so that the decorated names in the calling application match the exported names in the DLL's .def file.

Pros and Cons of Using __declspec(dllexport)

Using __declspec(dllexport) is convenient because you do not have to worry about maintaining a .def file and obtaining the decorated names of the exported functions. This method is suitable if, for example, you are designing a DLL for use with an application that you control. If you rebuild the DLL with new exports, you also have to rebuild the application because the decorated names for exported C++ functions might change if you recompile with a different version of the compiler.

What do you want to do?

• Export from a DLL using .DEF files

• Export from a DLL using __declspec(dllexport)

• Export and import using AFX_EXT_CLASS

• Export C++ functions for use in C-language executables

• Export C functions for use in C or C++-language executables

• Import into an application using __declspec(dllimport)

• Initialize a DLL

What do you want to know more about?

• Importing and exporting inline functions

• Mutual imports

• Decorated names

See Also

Concepts

Exporting from a DLL