I try to build SQLite v3 from source using VS2010 and run into problems which I do not know how to tackle.
This is what I have:
VS2010 pro.
using sqlite-amalgamation-3160100.zip
Microsoft article: SQLite databases
This is what I did:
Created a C++ 'Win32 Console application'.
Disabled procompiled headers.
Added preprocessor definitions: (dont do this, this is the problem!)
_HAVE_SQLITE_CONFIG_H;SQLITE_OS_WINRT;SQLITE_API=__declspec(dllexport);
(as specified by 'SQLite databases' section 3.)
Created config.h (which is empty for the moment.)
Included the source files from sqlite-amalgamation-3160100.zip in the project.
build.
I get a number of compiler errors
1> sqlite3.c
1>e:\andre\ontwikkeling\sqlite\sqlite-amalgamation-3160100\sqlite3.c(38515): error C2065: 'MapViewOfFileFromApp' : undeclared identifier
1>e:\andre\ontwikkeling\sqlite\sqlite-amalgamation-3160100\sqlite3.c(38515): error C2099: initializer is not a constant
1>e:\andre\ontwikkeling\sqlite\sqlite-amalgamation-3160100\sqlite3.c(38524): error C2065: 'CreateFile2' : undeclared identifier
....
... which I try to solve.
The first one leads me to the following code snipped:
#if SQLITE_OS_WINRT && (!defined(SQLITE_OMIT_WAL) || SQLITE_MAX_MMAP_SIZE>0)
{ "MapViewOfFileFromApp", (SYSCALL)MapViewOfFileFromApp, 0 },
#else
{ "MapViewOfFileFromApp", (SYSCALL)0, 0 },
#endif
Now 'MapViewOfFileFromApp' leads to MapViewOfFileFromApp function, 'Maps a view of a file mapping into the address space of a calling Windows Store app.', a valid microsoft call for which my project setup is missing the correct configuration.
I could get a workaround for this one, but other errors are depending only on SQLITE_OS_WINRT and as such not possible to work around it.
It looks like that I'm missing some configuration options but I do not know which ones. I read all of the documented compile time options but can't find out what it is that I do wrong.
I tried to find a working exaple of a VS2010 solution but came up with nothing. And of cause I checked here for similar questions! (If there is one covering this then I missed it, sorry.)
Does anybody have a suggestion on what I'm missing? I'm running out of idea's.
* edit 6 jan 2017 *
On advice of MaxFurry I followed the steps of the blog by David Cravey which does exact the same steps as I did but without declaring SQLITE_OS_WINRT;SQLITE_API=__declspec(dllexport);. Leaving these two defines out solved the problem.
Aparently I misinterpreted the advice in the Microsoft article.
Compile time problems solved.
Kind regards.
Do you have your sqlite3.dll file already built? If so just create a folder in your visual studio folder. When u want to use sqlite3 just copy the dll file to the folder of the project in visual studio u want to use it also copy the following files there sqlit3.c, sqlite3.h. When this is done open the project in your visual studio IDE. Right click on the project name, add, add existing then click on the sqlite3.h and sqlite3.c. Let me know how it goes.
Related
I have a CUDA project that originates from a C++ project. I will need to add CUDA code to different compilation units over time. Let's say I have two files, kernel.cuh and kernel.cu that contain my kernels' headers and bodies. Then, I change the extension of a module from .cpp to .cu, include kernel.cuh, and call my kernels using the < syntax (myKernel<<<blocksPerGrid, threadsPerBlock>>>). When I do this, I get an error in the module that says syntax error: < . The problem is that this file is still compiled by the C++ compiler instead of nvcc, and I don't know how to change that in Visual Studio manually. I thought the compiler was chosen according to the extension of the files. The problem wouldn't go away until I create a new project from scratch. Does anyone know how to fix this so that I will not need to create a new project?
For the question to get off the unanswered list, I will give a simple solution that solves the problem but does not answer my question about VS. I didn't have to make a new project from scratch. I only had to remove the file from the project and then add it again (Idk why I hadn't tried this before).
When I open a generated solution+project file, I get the following warning for each platform I have in the project file:
path/to/project.vcxproj : warning : Platform '[some_platform, 0]' referenced in the project file 'project' cannot be found.
some_platform is a valid platform in the project, and building, browsing etc all work normally. There is no line number showing where the problem is.
My question is, what does '[some_platform, 0]' really mean?
Coming from Linux, I initially thought the quotes signify that I have [some_platform, 0] literally specified somewhere, which I don't. I don't see ,\s*0 used anywhere in the project file either. How do I decipher that message to be able to find out what it's complaining about?
This is a C++ project if that matters.
Edit: The only places , is even used are inside two messages and an SDK reference. So the [some_platform, 0] is definitely something constructed for the sake of warning, but what does the second part (0) mean?
Resolved: Why VS generates an output like that, I don't know, and who knows what the 0 means. However, it turned out that the platform name is something an SDK would register with VS (or something along those lines) and VS expects it case-sensitive. I had changed ORBIS and Durango to orbis and durango, causing the warning. Fixing the case makes the warning go away (the project was loading and building fine regardless).
I think you might have unmatched solution/project platform and build configurations, resulting in the rare case when visual studio defines or creates new ones: https://msdn.microsoft.com/en-us/library/kkz9kefa.aspx ending in the odd platform names '[some_platform, 0]', '[durango, 0]' and '[orbis, 0]' you have.
Now this is entirely my guess (since I could not find any documents to confirm it). But what that 0 actually means, is the reference to the default build configuration that project should use when you target those individual platforms. For instance, you usually have lines similar to this in the solution (.sln) file:{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}.Debug|Mixed Platforms.Build.0 = Debug|Any CPU
In the case above you would use build configuration 0 as the default build configuration when using msbuild solutionname.sln from the console. But since the entire platform was generated for that project, we of-course don't have a default build configuration either, so... lets generate. There is more details and examples of the default build-configuration in this post: Visual Studio solution file - what does the "Build.0" mean?
Now back to what might actually be your real problem. You mentioned SDK references, have you made sure they are pointing to the correct place and any environment variables is properly configured in visual studio? If not, the problem might be related to the warnings mentioned here:
Platform 'Android' referenced in the project file 'san-angeles' cannot be found. The warning message on that question sure looks similar to the warning you have, only you have those oddly generated platform names.
Hope this will help you solve the problem.
And at first, sorry for my bad English. It is my first project in D. And my first project with SFML (DSFML of course).
I use dub for making Visual Studio project (I use VS2010). Then
open it and set up project settings:
general
compiler
linker
Autocomplete works correctly:
When I try build project, here is error:
Error 42: Symbol Undefined _D5dsfml8graphics12__ModuleInfoZ
How I can resolve it?
This particular error is saying that it can't find the actual D code for the library. It could mean that dub isn't grabbing/linking the source somewhere, but I've never used dub with an IDE so I can't be sure.
My suggestion to help you figure out what is going wrong and to fix this issue is to bug the maintainer (who is me, actually) on github by opening an issue about a lack of tutorials for the IDE's that are available to D right now.
If you want to get started with DSFML right now, however, you can sort of follow along with the command line tutorial and use that as a basis of figuring out what libraries need to be linked in, set up import search paths, etc.
Create project by dub init dsfml_test (where dsfml_test is our project name)
Add libs dependencies to dub.json
Generate Visual Studio project
Open project in Visual Studio
Open project properties
Enter path to directory where is placed dsfml lib files
Thats all. Now can add import dsfml.graphics, dsfml.window, dsfml.system; ...etc and build project.
I'm working on a C++ project (VS 2010) using CPLEX.
I have included the required cplex libraries in the project settings as follows:
added the "additional include directories" under C/C++ > general
added the "additional library directories" under linker > general
added the .lib files as "additional dependecies" under linker > input
Everything compiles fine, however my problem is that intellisense still reports errors (red squiggly underlines) such as "cannot open source file" in the #include line, and "identifier undefined" when using variable types defined in the CPLEX library.
The only difference with other projects that don't have this behaviour is that this time I have used windows environment variables in setting the include path, i.e. the library directories and include directories are defined similar to: %CPLEX_STUDIO_DIR%\cplex\include
I have set it like this so that I can build this project on different machines without messing around in the project properties. Since CPLEX is installed separately, using relative paths to specify additional directories is not really an option.
I'd like to repeat that the project compiles, it's only the intellisense errors that are bothering me.
I know I can turn off the intellisense error reporting, but if someone has a workaround for this I'd love to hear about it.
Kind regards,
This problem is known to Microsoft:
http://connect.microsoft.com/VisualStudio/feedback/details/779874/intellisense-cant-handle-using-environemt-variable-in-include-path
The only way I know of to avoid it is to manually enter the full literal path. The bug is marked "deferred" which I think means Microsoft has regarded it not serious enough to be fixed soon.
The solution is to replace %CPLEX_STUDIO_DIR%\cplex\include with $(CPLEX_STUDIO_DIR)\cplex\include. This is the syntax Visual Studio uses for its built-in variables such as $(VCInstallDir), but it also works for environment variables (so long as they don't have the same name as a built-in variable) and is recognised by intellisense as well as the compiler.
(I realise this is an old question, but it ranks highly in search results so it could help others even if not the original poster.)
I'm following the basic Allegro 5 tutorial to try to make my first basic Allegro project, but despite following the instructions to the letter I cannot successfully link to the libraries.
Here were the instructions:
Under Configuration Properties->C/C++->General, enter c:\allegro\include in Additional Include Directories.
Under Configuration Properties->Linker->General, enter c:\allegro\lib in Additional Library Directories.
Under Configuration Properties->Linker->Input, append allegro-5.0.5-monolith-md-debug.lib to Additional Dependencies.
Under Configuration Properties->Debugging, enter PATH=c:\allegro\bin;%PATH% in Environment.
Click Apply.
Visual C++ can now link your project with the Allegro 5 library.
You should now select the "Release" configuration (upper left corner) and repeat the steps with one minor change: use the non-debug library allegro-5.0.5-monolith-md.lib.
But then it gives me the following error nevertheless:
LINK : fatal error LNK1104: cannot open file 'allegro-5.0.5-monolith-md-debug.lib'
Ideas?
I didn't realize this was getting a bunch of views; I would have put up the answer eons ago. Hopefully people have been seeing my comment containing the answer--
Wow, answered my own question. You have to update the Linker Input file path thing. The current version is 5.0.6 -- just change that and it works.
Basically their installation instructions aren't updated to reflect the current version. Make sure you change things accordingly when changing project linker settings to include Allegro.