I am trying to compile a DLL with MinGW and use it from an executable compiled with visual studio compiler.
One of source files from DLL is using hash_map<> and it can be compile with MinGW successfully.
When I change hash_map<> to std::tr1::unordered_map<> and add #include <tr1/unordered_map> to my code it's compiling successfully for visual studio compiler.(How can I force MinGW to use tr1 namespace?)
But When I am trying to compile the code with MinGW as a DLL and use it from an executable compiled with visual studio compiler it's giving error: cannot open include file 'tr/unordered_map'
must My DLL be compatible with cl and MinGW same time?
EDIT:
my commands for compiling are below:
g++ -shared -o stemming.dll stemming.cpp alphabet.cpp basic.cpp determinise.cpp fst.cpp hopcroft.cpp operators.cpp utf8.cpp -Wl,--output-def,stemming.def,--out-implib,libstemming.a
lib /machine:i386 /def:stemming.def
cl sfstMinGW.cpp SFST/stemming.lib
VC++ is trying to open a header file and can't find it in the include path. VC uses the INCLUDE environment variable to determine the paths to use when searching for header files. Since VC does not use the tr/ directory it's not going to find it. You need provide include statements for both VC and g++ and choose which one to use like below.
#if defined(_MSC_VER)
# include <unordered_map>
#else
# include <tr/unordered_map>
#endif
You need to make sure that you compile the application using the same implementation of unordered_map used by the DLL. This means you will need to update the include paths to use GCC's version of TR1 instead of MS's implementation of the standard headers.
Related
I'm working with Embarcadero C++Builder 10.3.3, and would like to use OpenCV with it. However, the precompiled OpenCV pack is precompiled with Visual Studio, which uses the COFF format. However, the C++Builder 64-bit compiler uses the ELF format under Windows, per Upgrading Existing C++ Projects to 64-bit Windows:
Object and Library File Format
BCC32 and its associated tools use OMF in .obj and .lib files.
BCC64 uses ELF in .o and .a files.
Of course, I tried to compile the OpenCV source code with C++Builder, but I failed miserably. A Google search didn't find anything really helpful either, except that others also didn't succeed.
Does anyone know a CMake-compatible compiler that can generate object files (.o) and static libraries (.a) for Windows to compile OpenCV (for Windows, not for Linux, because BCC64.EXE is a Windows compiler)?
I'm also trying to use OpenCV with C++Builder (I couldn't write a comment because this is my first contribution!).
I could create the lib file with mkexp from the precompiled dll (opencv_world452.dll in \opencv\build\x64\vc15\bin) as Remy suggested.
But I have problems with the header files: How to set include path that the statement #include "opencv2/core.hpp" is accepted by the compiler? "core.hpp" also has such include statements. So, do we need to change all these #includes (\ instead of /)?
As a workaround you could try to use the Delphi-OpenCV library (https://github.com/Laex/Delphi-OpenCV) or install Python4Delphi in C++Builder and use OpenCV via Python.
I have a C++ program test.cpp and I want to link two .lib files to it(fhlib.lib and gc_lib.lib).I have the .lib files in the same folder as my .cpp program. I'm on Windows 7.
What I have tried so far is the following:
g++ -o main main.cpp -L/Users\Documents\Visual Studio 2015\Projects\My Project -lfhlib
But I get an
No such file or directory error.
I'm sure the path is correct because I copied it from Properties->Location. But I had do delete the "C:\", because it was not compiling.
EDIT: I found this http://www.mingw.org/wiki/Specify_the_libraries_for_the_linker_to_use.
So I tried using
"-I" instead of "-l"
But still doesn't work.I get:
undefined reference to 'fh_set'...
If you're compiling with g++ on windows, I guess you're using MinGW: MinGW relies on .a libraries. When using the "-l" option, the compiler is looking for a library file with the extension .a.
Libraries in the format .lib are compiled with visual studio: you can't use it as this. Compile your libraries with MinGW if you have the sources or consider migrating your project to visual studio.
So the problem was that the lib files where compiled in VS. And I had to use the VS compiler instead of g++ and everything worked fine.
Actually I'm trying to compile a c/c++ project with mingw. The same project is actually compiled with visual studio compiler. For this purpose, I have written a makefile and everything works so far.
During compiling I get error regarding functions which are declared withing string.h and stdio.h like memcpy() , printf()..., with following error:
error: 'memcpy' was not declared in this scope
That's because the compiler didn't find the functions. When compiling within visual studio, this error didn't appear, logically, because of compiler include paths like:
c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\
My question now is:
What should I do in my makefile to tell the compiler to use the "string.h" and "stdio.h" functions from the mingw. I tried to put the include path in the makefile, like:
INCLUDE_DIRS =\
C:\MinGW\include
but it has no effect.
And also, there is a difference between the string.h and stdio.h from visual studio and string.h and stdio.h used by gcc. Can this be a problem?
The correct way would be to add these includes to the source files where you use methods which are defined in them.
But if you insist to include it through the makefile, you can use force include.
Visual studio link.
To set this compiler option in the Visual Studio development
environment Open the project's Property Pages dialog box.
Open Project Property Pages.
Click the C/C++ folder.
Click the Advanced property page.
Modify the Force Includes property.
or use -include path_to_the_header for gcc
Just add this option to the compilation command line. Good luck.
I'd like to use a library I've compiled using Cygwin GCC (.a) in a Visual Studio C++ project. When I include headers from the library in VS, the ext/hash_map header is missing. Is that a header file I can just add and replace with hash_map, or is it all together hopeless (because the library doesn't make heavy use of hash maps)? Moreover, is it ridiculous to hope VS can use the .a library? Thanks!
You cannot mix GCC generated .a files with Visual Studio.
I just started a tutorial to learn C++ OpenGL using SDL. The steps shown in the videotutorial were done by using the IDE called Code Blocks, but I thought it was going to work also for Visual Studio 2012.
I downloaded the SDL2 developer which is for Windows x64 (my Windows 7 is 64 bits, but the Visual Studio 2012 I have is an x86 version)
To install the SDL2 in Visual Studio 2012, I put:
the .h files in the include folder (D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\SDL).
the .lib files in the lib folder (D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib\SDL).
the .dll file in C:/Windows/system folder.
After that, I opened the IDE, made a new project and while I was writting the code, autocompletion popped up for specific SDL features, meaning success... until I tried to run it.
This is the code I wrote according to the videotutorial:
#include "SDL.h"
int main(int argc, char* args[]){
SDL_Init(SDL_INIT_EVERYTHING);
SDL_Quit();
return 0;
}
When I click on "Start Debugging" or "Start without debugging", after pressing yes to build it, the output comes with errors.
Here's a screenshot of the code I wrote, plus the output:
After that, I tried an older version of the SDL the tutorial was already using, which was the 1.2 (I overwrote few files of the newer version) but still no good results.
How do I fix it so I can practice with OpenGL + SDL features?
TLDR:
When you use a library in your project,
Compiling needs header filenames (#include <*.h>) and include directories containing them
Linking needs lib filenames (*.lib, what you're missing) and library directories containing them
Running needs dynamic libraries (*.dll), commonly using the same name as the .lib in the current or system directory (VS has binary directories too but I've never needed to know what they're for exactly)
When you compile code and add #include <SDL.h>, the compiler runs through a list of possible directories its been given to find that file. There are some default directories already set up, but so you don't have a mess of all your libraries in one place it's possible to add more. For example, Setting Global C++ Include Paths in Visual Studio 2012 (and 2011, and 2010). If your SDL.h is in a subdirectory in an include directory it won't be found - eg. just check this shouldn't be <SDL/SDL.h> or something similar.
With the include path set and the correct #include your code can compile. Now it's the linking stage. You've got some code that says I need the these functions and the linker has to either find the actual code for those functions and link them statically (all the code can be found in the .lib) or set up the program to link at runtime, dynamically (in which case the program needs to be able to find the .dll, and I think on windows you need a .lib file that goes with it).
So in addition to the include directory you need a library directory. Also, just like you said to the compiler #include <SDL.h> you need to tell the linker to look for the code for those functions defined in SDL.h in SDL.lib (which may end up actually providing the code at runtime when loading SDL.dll). I think specifying libraries could even be done through #pragma calls, but it's more common to see the library files specified as arguments to the linker program. As #ScottMcP-MVP said, append SDL.lib to the Project Properties->Configuration Properties->Linker->Input->Additional Dependencies list. If it still says unresolved external that generally means the linker still can't find the file, so check for typos and double check the directories. Worst case is a mismatch between SDL.h and SDL.lib or SDL.lib was compiled with different options or a different compiler.
The error you're receiving is the linker saying the compiler says I need an "external" function, SDL_Init, to make your code work but I haven't found/resolved-the-reference-to one in the list of libraries I've been given.
Just as an example/recap all these GUI options end up going to the compiler/linker. So for example a full compile line might look like this:
./compiler -I/path/to/my/includes -L/path/to/my/lib -lmylibrary.lib mycode.cpp -o myexecutable.exe
Where mycode.cpp contains #include <mylibrary.h>. Note that here the ./compiler is operating as both compiler and linker. The process could be split into:
./compiler -I/path/to/my/includes mycode.cpp -o mycompiledcode.o
./linker -L/path/to/my/lib -lmylibrary.lib mycompiledcode.o -o myexecutable.exe
Once you have your executable it needs to be able to find SDL.dll when you run it. Exactly as you've done, the executable should search the windows system directory. It should also search its current directory. On linux you can set an rpath (not sure on windows). If you keep getting application configuration incorrect and the dll is definitely there it's time to grab dependency walker and see what dll name the program is actually trying to load. Worst case is the application finds a different version of the dll or something else with the same name before the desired one.
Good luck. OpenGL is great fun!!
[EDIT]
You can use either x32 or x64 lib files, but all your code must be the same. It'll probably be easier to start with x32, and if you need fast double computation and more ram then change. OpenGL doesn't have great support for x64 yet so it probably won't make much difference to you.
Additional Dependencies is where you put just "SDL.lib". This file then needs to exist in one of visual studio's library directories. If you don't get unresolved externals from SDL anymore then that part is fixed.
Your _main error is probably to do with a disgusting hack *spit* SDL uses. Straight after #include <SDL.h> put #undef main (may want to surround in #ifdefs in case it changes):
#include <SDL.h> //my include is <SDL2/SDL.h>, as I have both an SDL and SDL2 dir in my include path
#ifdef main
#undef main //remove SDL's main() hook if it exists
#endif
An important thing to note: generally use </> to include external libraries and "/" to include headers within your project - What is the difference between #include <filename> and #include "filename"?
You have to link the lib file into your exe. See Project, Properties, Link, Additional Dependencies. Put the name of the lib file there.