I have gone through all the procedures on how to compile V8 and actually managed to compile it on Windows platform. However, the problem is that the compilation procedure on Windows forces you to compile with Visual Studio and therefore creates object files (.obj) which can be used in VS. I have managed to create a DLL file too but it only serves the purpose when there is an executable to run.
On the other hand, I am using Eclipse and g++ on Windows. To embed V8 into my C++ I will need to have a library file (.a extension so that the linker will work). Is there a way that this is doable?
When the DLL was created an import library should have been created as well. They typically have the same name as the DLL but with a .lib extension. Add this library to your project in Eclipse and it should be linked in at build time. you can do this by right clicking on the project and selecting Properties -> C/C++ Build then go Library and add it there.
Related
I'm new to coding and Visual Studio. I know and understand how to create, save and compile a new C++ project in Visual Studio. I understand that a new VS project creates a solution file in the directory which then I can use to open the project, etc.
What I don't understand is how to compile a C++ project which doesn't have a VS solution file. I mean, do I have to manually create a project and import files and then build it?
Please take this GitHub project as an example. Under information, it clearly states the following:
Building
To build a static library (./lib/ompeval.a) on Unix systems, use make.
To enable -msse4.1 switch, use make SSE4=1. Run tests with ./test. For
Windows there's currently no build files, so you will have to compile
everything manually. The code has been tested with MSVC2013, TDM-GCC
5.1.0 and MinGW64 6.1, Clang 3.8.1 on Cygwin, and g++ 4.8 on Debian.
Now, what I don't understand is how do I build this project in my VS software so that I can successfully run it? Any help would be appreciated. Thank you.
As you said it, create a new project in Visual Studio and just import the source and header files. Looking at the makefile, there doesn't seem to be any pre or post build events so you can import the files and compile them right away (as long as the code is platform compatible ofc).
You may have to create multiple projects. One for the static library and one for the test files, since Visual Studio projects usually have one output type only. Mostly one of the presets: dynamic library (dll), static library (lib) or executable (exe).
I have one Windows project, a Linux project and a Shared Project referenced by both the first two projects.
I've set up everything necessary to build the Linux project with a Remote Debugger. Now when I try to compile a file individually in the Shared Project (Ctrl+F7), it defaults to trying to compile it with the remote compiler. Is there any way to choose which compiler to use when compiling individual files in the Shared Project?
I've downloaded and compiled zlib, and I am statically linking zlibwapi.lib to my C++ project on Visual Studio 2015.
However, if I don't use the dll and launch my program, it complains about it:
"The program can't start because zlibwapi.dll is missing from your computer."
With the DLL though, no error message shows up and the program works fine.
Is there any way I could use my program without the need of zlibwapi.dll?
I've done this with MSVC 10. I created a separate project for zlib and built it as a static library (.lib), which I then added to my main application project. The projects are not in the same workspace. I did have to build a separate copy of zlib.lib for 32-bit and 64-bit builds of my app, and the app itself uses MFC in a dynamic DLL. Everything links just fine, and zlib is not in a DLL.
I thought this should be straightforward but I am running into a bunch of linker errors like so:
Error 1 error LNK1104: cannot open file '...\Debug\Utils.lib' ...\LINK
where Utils is one of the C++ projects I want to keep as DLL.
If I change Configuration Properties->Configuration Type to Static Library(.lib) everything compiles and runs fine, but if I use .dll then its not working.
The whole solution is native C++ with the main project being a win32 console application.
Perhaps your library (Utils.lib) is not assembled as DLL and changes in console application project (that uses library) will not help.
Read carefully MSDN to see features of DLL's creation and usage.
It you try to link a .lib against another .lib, it doesn't really link. Instead, this instructs the final link to use both libraries.
For a DLL, this can't work, as the runtime linker cannot link the original .LIB. That means the link has to happen when the DLL is compiled.
As a result, a DLL project needs to have the .LIB directories set right.
I have a DLL that I compiled from source (gdal). I have a simple C++ Win32 console project that has one source file, but I want to link against that DLL. Currently, when I try to run the project, it compiles correctly, but says that it cannot find the DLL. If I move the DLL to the same directory as the DLL, the exe will run. Is there a way to make my output EXE include the DLL so that I can just move one file to another system and run it without having to send the DLL with the exe.
How can I make this happen in VS2010?
Unless you had the original source code for the .dll, recompiled as a static library (.lib) and then statically linked to it, I don't believe there's a way to "include" the dynamically linked library inside your executable.
You need the DLL in the path, or in the current directory for your application to run. That is how it works with DLLs.
With static libraries, the linking embeds the library code into your application. If you cannot or do not want to have the DLL available, you could change your DLL to a static library.
Since you are compiling it from source you can just add the source files to your project and build it right into your executable.
You could create a Post-Build Event in the Visual Studio project that runs a script to copy the DLL to the path of the executable.
Then, when you deploy your application, an installer would be able to take care of the DLL management for you.