On both linux and windows I see that the library import does not work for .c files, but does work for C++ extensions (.cxx). Is this a known intention / limitation or is there something different one must do?
I simply use:
extern “liba.so” void api_func1();
…
api_func1();
When the file is, say, test.c, CINT prints
"
Error: Function api_func1() is not defined in current scope test.c:15:
!!! return from main() function
"
It works fine for the same file when it is renamed to test.cxx
I tried LoadLibrary, GetProcAddress for the windows side of things (want to keep things as portable as possible) but it doesn’t recognise the pointer function as a valid call, even though the dll import works and returns a valid-looking address.
I read osdir.com/ml/lang.c++.cint/2004-08/msg00011.html and decided that having an #ifdef CINT block is not so bad and will probably not be of concern to end users, but requiring that end users use a specific non “.c” extension might be a little odd, especially if all binaries involved are plain C.
liba.so/dll is compiled as C++ with extern “C” and as just plain C and the behaviour of extern “liba.dll” is the same.
Right, I realise C and C++ don’t mix well which is why I want to expose the library as only C and use it only as C to keep things simple - we are targeting various platforms. The windows version will (probably) have to be implemented in C++ to access another C++ only dll, but it’s own API should be plain C.
I attach the code inline below. In the mean time, I noticed I simply need to call
"cint -A test.c"
to have it work. This does execute the C file in C++ mode, but it should be fine.
----------------- api.h ---------------- #ifndef API_H #define API_H #ifdef _WIN32 #ifdef API_EX #define EX __declspec(dllexport) #else #define EX __declspec(dllimport) #endif #else #define EX #endif #ifdef __cplusplus
extern “C” { #endif