I am a Java programmer and have come across a very nasty situation. For POC purposes, I need to write down a small segment of my solution that will run as a standalone application doing something very specific.
I have 2 questions:-
I can write the code, but what I don't know is how do I create an installer and exe out of that C++ code.
Secondly, I need to parse a sqlite db file and show its data in the application. Is there a sqlite windows dll or some C++ library or something that I can use, instead of asking the user to install sqlite (or doing it myself through the installer)? So basically, I don't want an extra program to be pushed in, just a dll or some C++ library..
Please let me know if you have an answer to either or both the issues that I'm facing.
Thanks
Compiling your code will turn it in to an executable. For distribution, you'll want to build it in Release mode. I'm not sure what version of Visual Studio you are using, but you might have a "Setup and Deployment" Project type which will enable you to create an installer. Failing that, you may have to look at InstallShield or a tool like that to ensure that the installer has all necessary files (such as the runtime libraries).
SQLLite is called light for a reason! The source code for it can be incorporated directly in to your project and compiled alongside the rest of the files (see: http://www.sqlite.org/selfcontained.html ). This means no external libraries are necessary to link against, and no extra DLLs need to be redistributed alongside your executable.
Related
I would like to know just how I can turn any code I write in either 'C' or 'C++' into an actual stand alone application or program I can run on windows without having to compile and run through visual studio. EX: like if I wanted to make a new type of calculator that would do complex math problems and use it without having to boot up VS all the time?
I'm not sure about your version of Visual Studio, but every time you build or execute your program Visual Studio will build an executable(.exe). You can copy and share this executable.
Depending on the stuff you use in this executable you might need to share libraries (DLL's) or change your linking options. It is possible to include all the extra tools you use in your application by instructing the linker to include them. This is called a static link. This makes your executable a lot larger. The other option would be a dynamic link, this would require the recipient of your application to have the same libraries (DLL's) as you had while developing your calculator. This would make your application a lot smaller, but depending on those DLL's.
Download a copy of cygwin and use it to install an opensource tools environment for C/C++. You will need as a minimum, a copy of gcc, and editor if you don't already have one, and bash/terminal or similar (you can also use cmd.exe, but the bash environment is much better.)
You can then create whatever programs you like without using Visual Studio. Welcome to the dark side...
I have read these two SO questions: Which runtime libraries to ship? and License of runtime libraries included in GCC? - both were very helpful but not quite what I was looking for.
I have always just written programs for use on my own machine, which has never caused me any problems, but now I want to start running software on other machines and I'm wary of the runtime requirements.
EDIT: See below example instead, this was misleading.
Specifically, if I write a C++ program on a Windows machine, compiled with gcc through MinGW, and want to run it on another machine:
Do I have to send the libstdc++.dll with my program?
Is this single file (I assume placed in the executable's directory) sufficient to allow the program to run?
Also, an identical example, except this time it is an Objective-C program. Is sending the libobjc.dll file to the other machine sufficient to allow the program to execute properly?
I am used to running programs on machines which have developer tools, etc, installed, but now I'm looking to run them on general purpose machines (friends', colleagues' etc), and I'm not quite sure what to do!
EDIT: In response to edifice's answer, I feel I should clarify what it is I'm looking for. I know how to identify the necessary DLL(s) (/dylibs, etc) that my programs use, (although I am accustomed to doing that work manually; I had not heard of any of the tools). My question was more "What do I do now?"
A more general example is probably needed:
Let's say I have written a program which has object files derived from C++, C and/or Objective-C(2) code. I have used some Windows API code which compiled successfully using MinGW's gcc. I also have a custom DLL I wrote in Visual Studio (C++).
I have identified which DLL's my program will use at runtime (one of which may be GCC's libobjc.dll, I'm not sure if this would/should make a difference on a Windows machine, but I want to make this as general as possible) - The "prerequisite DLLs".
I would like to run it on my colleagues' computers, most of which run Windows 7, but some now run Windows 8. Starting at the very start for the sake of completeness:
Do I need to transfer the prerequisite DLLs to my colleagues' computers?
What directory should I place them in? (exe directory / a system directory?)
Once in place, will the presence of these DLLs allow the program to execute correctly? (Assuming it knows where to find them)
Are there any other files that should be transferred with the DLLs?
Basically I'm trying to determine the entire thought-process for developing and running an application on another machine in terms of system runtime requirements.
When loading DLLs, the first place Windows looks is the directory that the exe is in. So it will probably work just fine to put the DLLs there.
For the Microsoft DLLs though, I think it makes more sense to ask your colleague to install the Visual C++ runtime, which is a redistributable package from Microsoft. Ideally you would make an installer using something like WiX and it would install that prerequisite for you, but it is OK to just tell your colleague to do it.
Be sure to include a license file with your software if you include DLLs from gcc, because the GPL requires it.
libstdc++ isn't necessarily sufficient. You almost certainly need libgcc too, but actual dependencies are liable to vary with your particular application.
The best way to determine what you need to ship with your application is to load your EXE into a program like Dependency Walker.
Just as an example, I've compiled a test C++ program which simply prints a std::string. As you can see, it depends directly on two modules other than those that come with Windows; libgcc_s_dw2-1.dll in addition to libstdc++-6.dll.
You should remember to expand the tree under each DLL to make sure that it itself doesn't have any other dependencies (if A depends on B, B might depend on C even if A doesn't directly depend on C).
If you're worried and want the strongest assurances, you could install Windows into a virtual machine (VirtualBox is free) and test your application inside it. If you use Microsoft APIs, you may wish to check the MSDN documentation to see with what version of Windows they were introduced and ensure that it aligns with your target minimum Windows version.
Update: As xtofl points out this won't cover libraries loaded dynamically using LoadLibrary. If you want to cover this base, use Process Monitor to examine what DLL files are touched when you run the application. (Add an 'Image Path' criterion with the path to your EXE in order not to get flooded.) This has the added advantage that it covers all files, registry entries, etc. that your application depends on, not just DLLs.
Suppose that I compiled a dynamic library (Windows DLL and/or Linux shared object file, .so) in debug mode for use by a client application that links to it dynamically. My source code is available to the client application developer.
I need some clarification regarding the following debugging scenario. I've always understood/assumed that in order for the client application to debug into my library
(for e.g. in order for a client application developer to step into my source code while debugging, say using F10 in MS VC++), that they would have to have actually built a local copy of my libraries themselves (with access to my source code), or atleast have local access to my source code without having built it (not sure if that would suffice?).
Am I right on this? In other words, I think it is not merely enough to provide libraries with debugging symbols (PDB files in MS VC++) if the client application is linking dynamically to my application which has itself been built dynamically. Appreciate if anyone can help sort this out for me? How about the situation in Linux? My understanding again is the same as the above. Now if I had compiled a static library (Windows LIB and/or Linux library .a); my understanding is that the they then don't need to have a locally build copy of my source code (I haven't tried this one out yet)?
Is/are my premise(s) correct? If not, can someone kindly provide some detailed explanation preferably with an example? Thanks for your input.
As requested, here's my comment as an answer. Since it only addresses the Windows side of things, anybody who has the Linux (or Mac!) part of the answer is free to edit it in (I've marked this as a community wiki answer).
For VC++, the debug build DLL + matching PDB + matching source is all you need. The hard part is getting them all to match ;-)
Also, it works more smoothly if the source files are at the same path as when the DLL was compiled, but Visual Studio is also perfectly capable of prompting you to browse to the source manually if you have it.
I have more experience with Windows than linux. But I would think the concept is similar.
if the client application is linking dynamically to my application which has itself been built dynamically.
I'm not quite sure if I understand "building dynamically". You might be confused with the dynamic aspect of dll? dll is linked at runtime (not build time) to allow a part of component to be deployed without a full app. For example, an app on Windows that rely on a dll provided by the OS are not impacted when Windows updates that dll as long as the interface is maintained. The only difference between a dll and exe is that dll's entry function is dllmain as opposed to main in exe.
(The only "dynamic build" concept I can think of is building templated classes. But I don't think that's what you mean here.)
Hence, debugging a .dll isn't different from debugging a .exe, it's just that .dll is a separate binary file from the executable. All the source code provide is allowing debugger to align the stepping with lines in source code. When source code is not available, then debugger can still step through assembly code with symbols.
When situation doesn't allow, then developers who are good at reading assembly code can do debugging with only symbols and no source code.
You can usually build a binary with optimized option, then compiler might optimize the assembly code so much that source code alignment in the debugger might not be possible. This usually happens with released code. In those cases when you step through the code, you sometimes see the line or condition jumps that are seemingly different from what you would expect. There is the same on .exe, .exe with libs, or .dll. This is probably why you thought it is always necessary to build your own binary to debug dlls?
I have a question how can I use wxSqlLite in my wxWidgets applications? I downloaded wxSqlite3 for wxWidgets 2.9x and build it but only static win32 debug win32 and static win32 release win32 compiled without errors. How can I add wxSqllite to my project? My ide is visual c++ 2008.
You don't NEED to use wxSQLite. You can simply call the SQLite API directly from your code. It takes an hour or two to get familiar with the API, but then it does everything you need without worrying about linking your build to yet another package.
The SQLite API is a library. There are several ways you can 'install' it. I have noticed that the SQLite site is a bit vague on this question. Here is what I do.
Download the zip containing the prebuilt DLL from http://sqlite.org/sqlite-dll-win32-x86-3071000.zip
This will give you the DLL, which should go in the folder where your executable runs.
This will also give the the export deefinition file ( .def ). This has to be converted to a .lib file so that it can be linked to. You do this using the lib utility.
You also need the sqlite3.h header file, which is included in the amalgamation downloaded from http://sqlite.org/sqlite-amalgamation-3071000.zip
If all this seems like a lot of trouble, you can alternatively use the amalgamation. Simply download the amalgamation and add the two files to your project. The downside with this is that you will have to build the SQLite code over and over again,slowing your build process, and the entire code will be statically linked to every executable. Nowadays builds run on modern computers so quickly that the cost of using the amalgamation is well worth the gain in simplicity. These days, I never use the DLL.
Of course one could use the SQLite API directly as ravenspoint pointed out, but wxSQLite3 makes it easier to integrate SQLite databases with wxWidgets-based C++ applications. The wxSQLite3 API is similar to JDBC and ODBC. wxSQLite3 takes care of converting wxString objects to and from UTF-8, one of the 2 encodings (UTF-8 or UTF-16) expected by SQLite; wxSQLite3 supports creating user defined functions as C++ classes; and adds several other features like backup and restore of databases, value collections, support for different date and time value representations and so on. wxSQLite3 can load the SQLite DLL at runtime without requiring a link library if you prefer, it's just setting a compile time flag.
Adding wxSQLite3 to a project is simple: either create a DLL or static library using the build files (including VC++ 2008 solution) coming with wxSQLite3, or just add the single C++ source file and few header files to your own project.
In case of difficulties ask your questions on the wxWidgets developer forum.
everybody, I am getting started develop a C++ project and in this project I must use some opensource project have several dll file. Then I have a question "How to build C++ project embed all dynamic link library in exe file?"
Thank for help!
Note: Sorry, I forgot that I'm using visual studio compiler on x86
There is no general answer to your question. It depends whether you need it to be cross platform or not.
However, since you're mentioning "visual studio compiler on x86", I bet you're targeting Windows. In such a case you have two options:
the official and recommended way: embed your dlls as resources in your executable; then when your program starts you extracts these dlls somewhere on the disk as temporary files (beware file permissions) then you use LoadLibrary + GetProcAddress
the hackish way: you write a PE executable loader in order to circumvent the fact that the Windows API only offers a way to LoadLibrary from a file on disk. By writing your own PE loader you'll be able to load a dll directly from a memory stream. Then again, I'm just mentioning it for reference but it's by no means something one should do
Finally, you need to comply to the license chosen by those opensource projects you're using. My answers gives technical directions about how to achieve your goal; it doesn't mean the license of the project you're using allows you to do so.