I have multiple source files in C++ using which i want to create a Dynamic link library.
I see this happening in linux with gcc -shared and ln
however for Windows i suppose i would have to modify source files to generate a DLL.
Is there a way to generate DLL (a file similar to *.so in linux) with provided source files. Please correct me if i m wrong, i think *so is dll for linux.
The reason for needing this is to use SWIG for calling C++ functions in python in Windows Platfrom. I am stuck at the step that requires me to generate a dll in windows.
The exact approach depends on which compiler you are using, but the procedure is probably documented. For example, if you want to create a DLL using Visual Studio, a walkthrough is available here.
DLL functions that are callable from outside the DLL have special macro keywords
__declspec(dllexport) void __cdecl SomeFunction(int a, int b);
What compiler are you using? For Visual C++ the command line that creates a dynamic library from the given object files looks like this:
link -nologo -dll -out:mylib.dll -implib:mylib.lib myobj1.obj myobj2.obj ...
Also while compiling your source files into object files you will need to use the -D option to define any macros necessary to ensure that your dynamic library's symbols will be exported.
Related
I am getting LNK2001 errors when trying to use Crypto++. The official advice for this is:
There are two ways you can deal with this, either change Crypto++ to export those classes, by using the CRYPTOPP_DLL macro, or link with both the DLL export library and a static library that contains the non-DLL classes and functions. The latter can be built by using the "DLL-Import" configuration of the cryptlib project.
It would be preferable to use the first option, and given that I am not experienced in using Visual Studio, I cannot find the location and execution method of the macro.
In short: Where do I find the macro and how do I execute it?
Cheers.
In short: Where do I find the macro and how do I execute it?
The macro is CRYPTOPP_IMPORTS. You use it when performing dynamic linking on Windows (i.e., the Crypto++ DLL).
You can 'execute' it in one of two ways. First, you can add #include <cryptopp/dll.h> to your stdafx.h. dll.h. defines it, and dll.h must be included before any other Crypto++ defines. Second, add it to your project's preprocessor macros. In either case, CRYPTOPP_IMPORTS will be defined.
I suspect you have a different error, though. You're probably not including the Crypto++ library (for static linking) or Crypto++ import lib (for dynamic linking) in your project.
I'd like to compile Lua 5.2 alpha under visual studio but I'm getting errors and I have no clue how to fix them.
error LNK1169: one or more multiply defined symbols found
error LNK2005: _main already defined in lua.obj
I'd be grateful if anyone could guide me through the creation of a VS2010 solution for Lua 5.2 alpha, or point me to related resources.
Thanks in advance.
You are most probably compiling both luac.c and lua.c in one VS project. To build Lua yourself in VS you need three projects:
library - this should be either DLL or static library project. Should include every .c file under src/ except luac.c and lua.c. You only need this if you are embedding.
compiler - console executable, containing luac.c
interpreter - console executable, containing lua.c
Sounds like you included lua.c, or luac.c, with another program. Each of these is a separate program with their own main. You need to include just one of them to build the standalone Lua component, or neither if you're embedding Lua in your own application.
The Lua source distribution includes a console interpreter, which already defines main, and you don't want that. Just look in the Lua source and delete or comment out the mains that you find.
These days, I use Flex & Bison generated some codes to develop a SQL-parser alike tools, these code can't compiled silently(may be this another topic) in VS2005,but GCC/G++ works well, then I compiled these code with mingw in dll(in windows xp), and then linked these function facades in VS2005, but it seems can't link the dll during linking.
Does MS VS2005 recognize the dll which compiled using mingw on windows? Is there anything I need to do additional? For example, adding something in the include-file that declare the exported APIs?
Does any one can give some advices?
The condition is, as in VS2005, if you want to export some APIs, you may show a *.def file to tell nmake which API you want to export, and then you may create a(or some) *.h file to declare somthing about these APIs(adding some stdcall alike prefix as a call protocal) and some data-type definition. But with GCC/G++, you do not need to do such boring things, just use [ar], you can get these APIs, so my *.h file do not add call protocol and no *.def, just like common function declaration. After *.dll generated, add the *.h file and [mv] generated *.dll in VS2005 project directory, then set the linking *.dll in project setting. Does these steps generated my Question?
BTW, I found and tested VC6-compiled dll can be linked with mingw in Windows XP, but the reverse can't work.
Anyway, forgive my poor English, and thanks for your concern.
VS2005 does not recognize any DLL to compile anything, and I doubt mingw does.
When your application shall use a DLL, you need to tell VS2005 what functions are provided by the DLL.
Load Time Binding
The entry points are defined in the EXPORT directory of the DLL. The content of the EXPORT directory can be defined with the DEF file, while compiling the DLL. Theses exports can also defined using the #pragma __declspec(dllexport) directive. When you compile the DLL the linker will also generate a *.LIB file for the consuming application. This LIB is called import library.
The signatures of the exported functions must be provided by function prototypes, usually in a *.h file.
When you compile your application with load time binding, you include the *.h file in your source code and add the import library to the project settings. (not the *.DLL) When the O/S loads your application, the static code in the import library will load the DLL, read the EXPORT directory and fix all stubs to access the exported functions (and other symbols).
Dynamic Binding
You can omit the import library and load the DLL with your code using LoadLibrayy at the time that's appropriate. You need to define the pointers to the DLL entrypoints by yourself and must intialize theses pointers before calling GetProcAddress the actual functions.
When developing and deploying native Windows applications, I often need to install a runtime before being able to run my binary, or statically link the library with my binary. For instance, after building a "Win32 Console" project with Visual Studio 2008, attempting to run the program on a fresh Windows 7 image results in:
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.
Issues like this one have been brought up in other posts on StackOverflow.
How does one develop applications that don't require runtimes that aren't already on the target OS (i.e. don't require installing redistributable packages or private/shared side-by-side assemblies)? How does one avoid using msvc[mpr]90.dll and just use the Windows API in \windows\system32*.{dll,sys}?
I'm thinking along the lines of the code that comes out of the demoscene, but that's frequently not made available.
Others have already responded with respect to linking CRT statically. If you also want a small binary at the same time, then your best bet is forego CRT entirely, and use only Win32 API functions as much as possible. You'll still get some CRT code, most notably related to startup (i.e. that which calls main) and shutdown (atexit handling etc), but otherwise the linker won't link CRT functions that you do not use.
You can avoid linking CRT altogether by using /Zl compiler switch. This means that main will no longer work, however - you'll need to define WinMain (name doesn't matter, but signature must match, and it must be __stdcall), and you will have to specify the name of your WinMain-like function as an entry point via linker /entry: switch. This will save you ~30Kb of CRT code (tested on a .cpp with an empty main).
If you go the latter route, you might also have to deal with issue of compiler intrinsics. There are some functions that are nominally defined by the CRT (and declared in its headers), but which are treated specially by the compiler, so that it inserts optimized assembly instructions at the point of the call where possible - examples are memset, strlen, and a good chunk of functions in <math.h>; a complete list can be found here. Since you don't have CRT, if you need these functions, or could avoid it but prefer the intrinsic because of improved performance (hard to do better than memset, for example), then you have to declare them yourself, and use #pragma intrinsic. E.g.:
// Contains macros and typedef only, so safe to include without CRT.
// We need it here for size_t.
#include <stddef.h>
extern "C"
{
int abs(int);
void* memset(void*, int, size_t);
}
#pragma intrinsic(abs, memset)
int __stdcall main(void*, void*, char*, int)
{
char tmp[10];
memset(tmp, abs(-123), 10);
return 0;
}
The above can be compiled with:
cl /c /Zl foo.cpp
link /entry:main foo.obj
Link the CRT statically via the /MT switch (and likewise MFC, if you're using it).
Static linking limits what you can do with DLLs somewhat, but for simple executables it works like a charm. (And if you're shipping DLLs, you can always ship private assemblies anyway.)
Use the static CRT. This doesn't create a dependency on msvc*.dll. The CRT is linked directly into your program. This doesn't create dependencies, but does increase the size of your executable.
More info on different CRT options here.
Statically link the runtime. MS Visual C++ has option /MT for that (default is /MD)
I think one way to do this is to just not use Visual Studio and instead rely on the command line SDK tools. (You can alternatively figure out how to config VS to do what you want, but that seems harder.) E.g.:
cl /c app.cpp
link app.obj ws2_32.lib
I'm using Visual Studio .NET 2003, and I'm trying to port code I've written and compiled/run successfully in Linux GCC to Windows.
I'm a newbie when using VS. I've created a new project, and added all the .c and .h files I have into the project by Project -> Add Existing Items, then chose all the .c and .h files.
I'm not familiar with how exactly compilers and linkers etc work, but is there a difference between how VS and gcc compile/link #include files? My habit of programming in Linux has been to have one main.c file, and #include all other .h or .c files that I need. Then I would only compile the main.c file. But in VS, it seems as if the #include files are not "seen" by the program, because I'm getting errors that tell me certain structures or variables were not declared, even though they are in my user-defined header files.
I'm also getting errors like DIR is an undeclared identifier. I've included , so why can't it recognize DIR?
Thank you.
Regards,
Rayne
Consider compiling your program with windows port of gcc (from Mingw32 or Cygwin) first. This will provide you with more familiar environment. If you'll still have to compile everything with VC++, you'll have more incremental process of porting.
Also, it is not evident from your post, but it seems you are trying to use dirent.h. Note that dirent.h (and corresponding libs) is not included with VC++.
One of the best ways to learn would be to start with the smallest application that you can compile on both. Expand this working and portable application step by step into the more fully featured application you desire.
Remember to add all .c/.cpp files to the 'Source Files' directory in the project as they won't be compiled otherwise.
Restrict any non-portable code (that you will need) to a single place. For example if you need to create threads, have a common create thread function used throughout (but implemented differently). Using portable libraries such as Boost can help here.