I have a static library called X.a and a cpp file called Y.cpp. Y.cpp conatins the main function and uses the functions in X.a. How can I compile Y.cpp such that X.a is included and finally make a Z.a which also includes Y.o ?
Related
C++Builder's 32-bit compiler, bcc32, by default creates shared libraries using the cdecl calling convention, prefixing exported functions with an underscore,
e.g. '_functionName'. Visual studio, on the other hand, don't prefix exported functions.
Python, when importing a pyd module, expects a function named PyInitialize_modulename. Since bcc32 prefix this function with an underscore, rendering it to be _PyInitialize_modulename, Python will not be able to import a bcc32 created module.
Using CMake, does anyone know how to add a module definition file, .def, to alias the prefixed function, to an 'unprefixed' one, when compiling/creating the pyd module?
Update. In response to Mr. Lebeau's answer below (as a comment);
This question is not about CTypes, but SWIG. CTypes allows for a simple way to wrap a C/C++ DLL, but mainly deals with C structures and POD data.
Swig, on the other hand, allows a client to get object oriented objects in Python, analogous to the ones exported from a C++ DLL. Swig can do this as it process C++ headers.
Swig does create a C++ file that is compiled into a .pyd file (in essence a DLL as noted). The first exported function that Python looks for when trying to load it as a module, is Pyinit_MyModule (Python 3). When using C++ Builder, this function is exported as _Pyinit_MyModule, as mentioned. Problem is that it is Swig that exports this function, and I can't as a client of Swig change the calling convention (afaik) for this function.
I believe my initial belief that Python needed __stdcall for this functions is wrong, as VS by default is using cdecl, but without adding the '_', and it that works fine.
However, setting the compiler flag to suppress underscores don't work either, as then some of the functions in the Python import libraries are rendered invisible, and become unresolved externals. So perhaps this problem is more complex than it may first look. But I guess it has nothing todo with calling conventions.
cdecl is simply the typical default calling convention that every C++ compiler uses. If you want to use stdcall instead, you can certainly do that (makes sense why Python would expect stdcall since that is what the Win32 API uses).
In the module's C++ code, you can use __stdcall explicitly in the exported function declarations.
Or, you can change the default calling convention in C++Builder's project settings, and then omit any calling convention in the function declarations.
Now, to answer your question - when importing a pyd module, if the module uses cdecl, use ctypes.cdll to call its functions. If the module uses stdcall, use ctypes.windll instead. This is covered in Python's documentation:
https://docs.python.org/3/library/ctypes.html#loading-dynamic-link-libraries
16.16.1.1. Loading dynamic link libraries
ctypes exports the cdll, and on Windows windll and oledll objects, for loading dynamic link libraries.
You load libraries by accessing them as attributes of these objects. cdll loads libraries which export functions using the standard cdecl calling convention, while windll libraries call functions using the stdcall calling convention. oledll also uses the stdcall calling convention, and assumes the functions return a Windows HRESULT error code. The error code is used to automatically raise an OSError exception when the function call fails.
https://docs.python.org/3/faq/windows.html#is-a-pyd-file-the-same-as-a-dll
Is a *.pyd file the same as a DLL?
Yes, .pyd files are dll’s, but there are a few differences. If you have a DLL named foo.pyd, then it must have a function PyInit_foo(). You can then write Python “import foo”, and Python will search for foo.pyd (as well as foo.py, foo.pyc) and if it finds it, will attempt to call PyInit_foo() to initialize it. You do not link your .exe with foo.lib, as that would cause Windows to require the DLL to be present.
After some fiddling around, I can say that it is possible to create Python extensions using the C++ Builder compiler, swig and CMake.
Below is a brief overview of the steps that I used to wrap a simple C++ class (ATObject) to Python37.
The C++ header file is:
#ifndef atATObjectH
#define atATObjectH
#include <string>
//---------------------------------------------------------------------------
using std::string;
int MyTest(int r);
class ATObject
{
public:
ATObject();
virtual ~ATObject();
virtual const string getTypeName() const;
};
#endif
and source
#pragma hdrstop
#include "core/atATObject.h"
//---------------------------------------------------------------------------
ATObject::ATObject() {}
ATObject::~ATObject() {}
const string ATObject::getTypeName() const
{
return "TYPENAME NOT IMPLEMENTED";
}
int MyTest(int r)
{
return r;
}
1) Create import libraries using implip on the Python3 and Python37 dll's. Use implibs flag -aa, to get an import library that C++ builder understands. Put them in the Python37/libs folder.
2) Create the swig interface file that defines which class, functions and data to wrap. The swig interface file:
// atexplorer.i
%include "std_string.i"
%include "windows.i"
%module atexplorer
%{
#include "atATObject.h"
%}
//Expose class ATObject to Python
%include "atATObject.h"
3) Create CMake files for the project, using SWIG_ADD_LIBRARY to create the .pyd module, e.g.
SWIG_ADD_LIBRARY(atexplorer MODULE LANGUAGE python SOURCES
atexplorer.i ${ATAPI_ROOT}/source/core/atATObject.cpp )
SWIG_LINK_LIBRARIES (atexplorer
${PYTHON_LIB_FOLDER}/Python3_CG.lib
${PYTHON_LIB_FOLDER}/Python37_CG.lib
)
and make CMake pass the .def file to the linker by adding:
set (CMAKE_MODULE_LINKER_FLAGS ${CMAKE_CURRENT_SOURCE_DIR}/atexplorer.def)
The atexplorer.def file should look like this:
EXPORTS
PyInit__atexplorer=_PyInit__atexplorer
4) Compile the project, and confirm that you get a generated "MyModule"PYTHON_wrap.cxx and a MyModule.py file in your CMake build folder. The "MyModule"PYTHON_wrap.cxx file contains generated C++ code for the Python module, and the .py file contain generated Python code.
The Python module is named atexplorer.
Image below shows what is exported in the _atexplorer.pyd module.
Copy the .pyd and the .py files to Pythons site packages folder.
If successful, you will be able to import the module in Python, e.g.
The screen shot above shows how the module, atexplorer, is imported. It has a function called 'MyTest', that returns whatever its argument is, when executed.
It also has a class, ATObject, for which an object named 'a', is created. Last line prints the output of executing the class member function 'getTypeName()', which simply returns, TYPENAME NOT IMPLEMENTED.
I have an application that links a static lib both build with visual studio (same version, same machine).
This lib contains multiple c files with mutliple functions (as usual :)
as an example
lib1.lib
file1.c
func_f1_1
func_f1_2
file2.c
func_f2_1
func_f2_2
prog1.exe
(links lib1.lib)
main.cpp
uses func_f2_2
strange.c
func_f1_1 (same signature, different definition)
func_f2_1 (same signature, different definition)
lib1 is independently build from prog1.exe
During link time the compiler complains about
lib1.lib(file2.obj): error LNK2005: _func_f2_1 already defined in strange.obj
The linker does not complain about func_f1_1!
I do not fully understand this kind of error since i expected that the linker only grabs symbols from a library that are not defined in the target executable.
It seems to me that the linker tries to put in the content of the whole obj from the lib instead just the function.
Are there any project settings that can i change to get the linker working on a function level? "function level linking" is activated in the compiler properties of both the lib and the program project.
If your program uses func_f2_2 then the linker adds the object file lib1:file2.o that defines func_f2_2 to the object list. All symbols in that object file are linked in to the program. This includes all variables that might be used by func_f2_2 as well as func_f2_1.
The linker doesn't complain about func_f1_1 since there was no reason to load the object file lib1:file1.o
If you need to replace func_f2_1 you have also to add the definition of func_f2_2 in strange.c.
I have a small issue when it comes to writing a DLL in MSVC (the 2010 version in particular).
My program consists of the main part and a DLL. The DLL contains a function that is
__declspec(dllexport) int test_function(void) {
return 42;
}
The file is compiled using a DLL project (not using pre-compiled headers, I have chosen a empty DLL project). Now, when I want to list the exported symbols using the dumpbin tool, the test_function is not listed under exports. Is there a specific setting that forces __declspec(dllexport) to actually export symbols?
Any help is welcome. Thank you!
That should do it. If this is the whole code, check the following:
1) You are actually checking the correct dll. Look at the timestamp. Double-check the location and the name.
2) You are compiling the specified cpp (I take it your definition is in the cpp file). Just because the file is in the directory doesn't mean it gets compiled, make sure it is added to the project.
3) Make sure your function is not excluded from the compilation unit by preprocessor directives.
Also look for other symbols and try to see what differences are there between the symbols that get exported and your function.
If this fails, you should move __declspec(dllexport) to your .h file and the definition (without __declspec(dllexport) ) to your .cpp. It might not be exported because the compiler might try to optimize it out by inlining it.
I have two existing executables A and T, in the same solution that both ran just fine before I touched them. In executable A is a header defining a class P, and a prototype for a static instance MyP. The definitions are compiled in project A. In executable T, I wanted to call member functions of MyP in project A, so I added dllimport/export macros to the declarations of the class and MyP in the headers (not at the definitions), and included the headers in project T. The dllimport/export macros are standard, and A_EXPORTS is defined in project A, but not in T.
#ifdef A_EXPORTS
#define A_API __declspec(dllexport)
#else
#define A_API __declspec(dllimport)
#endif
//various definitions and includes, defining ENUM_RECORDING_TYPE and ERROR
A_API HFILE viosopen(const _TCHAR *path, ENUM_RECORDING_TYPE rt, int flags);
A_API struct P {
ERROR B(SHORT phraseNum);
};
A_API extern P MyP;
I added project A as a dependency on project T in the solution. A still compiles fine, but T comes up with unresolved external symbol "__declspec(import) <snip> referenced in function <snip> for the function calls, and unresolved external symbol "__declspec(dllimport) class P MyP" <snip> for the static object. I also see in the output log, right after it starts linking: Creating library Debug/A.lib and object Debug/A.exp which seems ominous since it's supposed to be linking against the existing executable.
My question is: how can I tell MSVC 2010 where those are? I thought simply setting A as a dependency would have it figure that out automatically. I can link against the existing executable, right?
To statically link your program you don't need the __declspec() stuff and you don't need a separate project to create a LIB file. I think you can just link using the .obj file from your A project.
Your A project has a header file and presumably has a .cpp file that contains the implementation of the items described in that header. Let's say your header file is foo.h and the associated implementation is foo.cpp. When compiled, there should be a foo.obj intermediate file in the <solutiondir>\A\Debug or <solutiondir>\A\release intermediate folder. That file can be used by the linker.
In project T's properties, find Linker | Input and change the "Additional Dependencies" property to include the foo.obj file. One approach would be to use a relative file path to locate the file - for example ..\A\Debug\foo.obj in your debug configuration. Another approach is to use the simple file name in "Additional Dependencies" - foo.obj - and then use Linker | General | Additional Library Directories" to help the linker find the file - e.g., ..\A\$(IntDir). Using the $(IntDir) macro has the advantage that the same value works for Debug and Release settings.
Remember to set up a build dependency from your T project to your A project to be sure the A project is compiled first. Otherwise the foo.obj file might not exist when the T linker comes to look for it. In the Solution properties, select Project Dependencies and then set Project T depends on Project A.
To dynamically link you need to use the A.LIB file as #ajay said. The __declspec(DllImport) tells the compiler what functions and data you are importing but doesn't tell it where you are importing those things from.
Using the A.LIB file as input to the linker is much the same as using the foo.obj file in the statically linking case except that the lib file ends up in the solution output directory <solutiondir>\Debug instead of the project intermediate directory <solutiondir>\A\Debug.
This walkthrough on creating and using a DLL might be useful background.
I asssume project A is DLL not an EXE, which is successfully producing a LIB file.
You need to use the A.LIB as Linker Input in project B. Just producing LIB file wont make other projects automatically link to it.
I have a myheader.h file, i have included it successfully in my VC++ project, but i am not able to use any of it functions. It gives the error Unresolved external symbol (my function definition). What am i missing?
//Here is my code snippet
#include "myHeaders/myheader.h"
void main (){
head_gen();
}
It doesnt build and the error is
Unresolved external symbol void__head_gen()
etc. Has it something to do with .lib file or something else?
You need the implementation of the function head_gen(). This can be in
a source file,
an object file or
a library
You should have one of them gotten with the header file.
If you have a .cpp file, add it to your project.
If you have a .obj or .lib file, add it as dependecy in the Project Properties:
Configuration Properties / Linker / Input -> Additional Dependencies
If the .obj or .lib file is in a different directory than your project, don't forget to add the path:
Configuration Properties / Linker / General -> Additional Library Directories
I develop mostly on Linux and use vi as an editor. But when I see such errors, it usually is one of the following reasons:
The function head_gen() is defined under a namespace and the source code where head_gen() is used does not have the using namespace statement.
Has head_gen() been defined in myHeader.cpp? That could be another reason why the function is not "visible".
HTH,
Sriram