Trouble exporting symbols for a dll from multiple include files

[Greg Flynn]

I am trying to create a dll whose symbols are defined in multiple include files. In particular, I have typedefs which are defined in one include file and referenced in other include files. This presents no problem when I create a static library; however, if I try to create a dll, CVI is not able to resolve the typedef references when exporting symbols (the error is "syntax error; found 'identifier', expecting '}'", where 'identifier' is the reference to the typedef declared in a different include file). Oddly, this error does not occur for every reference to a type which was declared elsewhere;

[Chris Matthews]

I couldn't tell you what is happening without seeing the project. Have you tried just marking the functions for export with the qualifier __declspec(dllexport) or export. Then, just set your export setting to Symbols marked for export.

Best Regards,

Chris Matthews
National Instruments

[Greg Flynn]

Chris,
Yes, I tried that and it didn't help. In short, here's the problem:

include file a.h is:
-------------
typedef struct {
int dummy;
} MyStruct;

-------------
include file b.h is:
----------------
typedef struct {
MyStruct dummy;
} MyOtherStruct;
----------------

I am exporting b.h. a.h is part of the project (as is a.lib), but is not exported. The compiler (exporter?) is not able to resolve the reference to 'MyStruct' in b.h.

Because of the structure of the code, I can't include a.h in b.h. (Basically, a.h is the include file for one library, and b.h is the include file for another library. Library b uses functions and definitions from library a. Applications can use functions and definitions from either a or b or both.
Since library b is built on library a, an application using library b must also include a.h, listed above b.h)

I am working around this by creating special include files, e.g.

include file b-dllexp.h is:
-----------------------
#include

typedef struct {
MyStruct dummy;
} MyOtherStruct;
----------------

Applications still use b.h (with a.h listed above it), but when creating the dll, I export from b-dllexp.h. Unfortunately, I now have two copies of everything in b.h (b.h and b-dllexp.h). This is not a good thing from a change management point of view.

Note: this problem exists even if library a is the ansi_c library. E.g., if a.h = ansi_c.h, and
include file b.h is:
----------------
typedef struct {
FILE *dummy;
} MyThirdStruct;
----------------

I can't export (i.e., 'FILE' is not recognized) unless 'ansi_c.h' is included in b.h.

[Chris Matthews]

Yea, sorry I was unclear with how you were doing things. Yes, it does require that you have #include statements in the header to resolve the struct symbols. The export symbols process is done outside of the compilation process and compilation would be required to see the header order in the C file. Also, say you had the correct order in one C file and the incorrect order in another, would we throw an error in the exporting of the symbols? Also, doing it this way makes it easy for the DLL user to make a mistake and mess up the order of the headers and would also require you distributing multiple headers with the DLL. All in all, a bad programming practice. You should always include those dependency headers in the header with your exports.


Best Regards,

Chris Matthews
National Instruments

[Greg Flynn]

Chris,
Right - my bad. Basically, what I forgot was the old

#ifndef _HEADERFILE
#define _HEADERFILE

blah, blah...

#endif

trick. So I was getting multiple definition errors when I included the dependency headers in the library headers, so I took them out, so....

Thanks for the hand-hold.