I am trying to get Google Or-tools to work, I followed this tutorial to install it: https://developers.google.com/optimization/install/cpp/windows.
After running the tools\make test.cc, I created new C++ project, added includes of the library to C/C++ additional includes. When I try to build/run I got errors like these: https://i.imgur.com/0VuWNcg.png.
I have win7 64bit and MSVC 2019 so it is a bit different than theirs configuration but this does not seem to be connected.
The identifier errors look like this: https://i.imgur.com/B4YMqM9.png
The error in optional_boolean looks like this: https://i.imgur.com/Wr2l1Xv.png
Does anybody knows what is happening? Does their code have errors or am I doing something wrong?
(I also tried to compile directly from the source but bumped into different problems...)
You changed the includes, but did you change the libraries to link with.
Anyway, you should have a look at:
https://github.com/google/or-tools/issues/1449
I finally managed to get it working. The problem was faulty distribution of google or-tools. At least the problem was with library used by or-tools while using MSVC - it can be some sort of mutual incompatibility, I really don't know, but still they couldn't have tested it and I don't understand how that can happen and get into release).
Steps to solution were these:
Grab this version of or-tools:
https://github.com/google/or-tools/releases/tag/v6.10
Extract it where you wish to have it.
A If creating completely new project:
Grab this (thanks to #Laurent): https://github.com/philippe3263/ORTools_Visual_Studio
Reconfigure include path, lib path and in Linker->All Options remove/delete Additional Options.
B If editing existing project:
Set x64 debug profile.
add include and lib paths.
Add ortools.lib to extra libraries.
Add preprocessor directives _WINDOWS NOMINMAX USE_CBC USE_CLP USE_BOP USE_GLOP
It's possible that other settings are necessary like C/C++ -> Code generation -> Runtime library to /MD but since I already had a lot of custom settings I can't tell what is needed. (but checking the link and going through those settings can help)
Tested on Win7 64bit with VS 2019
Related
There is a Visual Studio project which refers to opencv_world440.lib but it does not seem to be available on vcpkg.
I understand vcpkg has opencv 4.3. In order to proceed I tried to remove opencv_world440.lib from
VS, project, properties, linker, input, additional dependencies and the project build successfully then. But when I tried
to run it return an application error
The application was unable to start correctly (0xc0000017).
I'm not sure what is going on here. May I conclude the project actually does not depend on opencv_world440.lib
because it build when I remove it?
Try to use dependency walker to see if it's something related to libraries. Anyway that error code stands for STATUS_NO_MEMORY as described here which indicates a problem with memory (can also be something OS level!?), sorry but I cannot be more specific.
EDIT
"opencv_world" appears to be just one DLL holding all the OpenCV modules, making it easier to distribute. The alternative is to have one library per module. So I guess if you have all the other libraries and it builds, you don't need opencv_world. In few worlds you cannot build a project if you don't have all the necessary libs.
I am somewhat of a beginner when it comes to open source libraries. I have tried to compile from source and use the pre-built binaries, but in both cases I get a ton of errors when I try to run the simple 'Hello World' program on the tutorial section of the wxWidgets website. After playing around for quite some time, the closest I have got to compiling is by building the libraries from source, but I still have 2 errors remaining:
"_w64 can only be specified on int, long, and pointer types" file: defs.h
"cannot open file 'wxbase31ud.lib" - LINK
It seems strange to me that the header file provided by wx would have an error such as that one, so I imagine both errors are because of something I am doing. I am hoping that someone here can do one of the following for me:
Help me solve these errors
Provide instructions for building libraries from source and subsequently linking my program to the correct directories
Some additional info: I am working on x64 Windows 7, my target will also be x64 exclusively. I do not have admin privileges, so no editing the system PATH for me.
Thanks for your help!
The simplest way to start working with the library is this:
Grab the sources.
Unpack the sources.
Open VS IDE.
Open \build\msw\wx-vc14.sln (adjust as necessary.)
Go to "Build->Batch Build...", click "Select All", "Build".
Go drink some coffee or watch TV.
After the build finishes, open wxWidgets/samples/minimal/minimal_vc9.sln.
Let MSVC convert the solution to become an appropriate format.
Build and run the sample.
If you will acquire any issue during those steps, let us know.
The library build in step 5 should build without any issues and then all you will need is to build the minimal sample.
The next step is to copy the samples\minimal folder somewhere and start writing the code. All you will need to do is to change the Include and Lib search path.
[EDIT]
If you can build the 32-bit libraries (which are default in the provided solutions) all you will need is to convert them to be 64-bit and rebuild.
There is no changes to the $PATH or any environmental variable involved. Moreover you shouldn't build anything with the admin priviledges.
Also as Thomas pointed out you library build has to match whatever sample you are trying to build.
[/EDIT]
I am currently using Visual Studio 2013 (Update 4) for building Qt5.4.0 projects. I use the express version so I don't use the VS plugin. My .vcxproj files a generated from .pro files using build scripts and qmake.
When debugging my projects I sometimes try to step into Qt library code. To do this I added the path to the Qt source codes to the solution properties->Debug Source Files setting like described in a former post (VS2013 debugger can not find Qt sources).
Because I have many different projects and it would be a pain to update all of them in case of a Qt update I used a system environment variable "QTSRC" pointing to that path and added the following line to the solution:
$(QTSRC)
This worked like charm some time ago (with an older update of VS and a former Qt version 5.x).
But unfortunately it does not work anymore. It seems that VS now totally ignores the system environment variable (it also does not show any errors when I check the "check entries" button in the dialog).
Does anybody know what changed here lately and what must be done to fix this? It would be very annoying to add the path hardcoded to every project (which still works) and have to do this over and over again after Qt updates.
I'd look at the Property Pages which will allow you to set user defined values that you can share across different projects:
http://msdn.microsoft.com/en-us/library/675f1588.aspx
I use them to set global include paths, but it looks like you can set almost anything there. Set things in the .User pages if you want them used for all your projects but not included in the solution or project file itself.
A good, short, guide is here:
http://www.curlybrace.com/words/2012/12/17/setting-global-c-include-paths-in-visual-studio-2012-and-2011-and-2010/
I have updated my Ubuntu box to 11.10 and then Eclipse also have been updated to 3.7.0 Indigo with CDT 8.0.1
Then the following problem occurs:
I have included the vector header file but the compiler said that Symbol 'vector' could not be resolved. I also defined #define int Comparable, but Eclipse also said Symbol 'Comparable' could not be resolved and so on....
Although lots of errors occur, compiling was finished successfully!
I have tried to use g++ to compile the code, it had no problem.
The problem is that there are a bunch of include directories that are missing from the indexer's perspective.
Adding the following worked for me, but may depend on your particular setup where they actually exist:
/usr/include/c++/4.6.1
/usr/include/
/usr/include/c++
/usr/include/c++/4.6
/usr/include/x86_64-linux-gnu
/usr/include/asm-generic
/usr/include/c++/4.6.1/x86_64-linux-gnu/
They can be set in Project>Properties>C++ Include Paths
Presumably, in the future, the platform specializations for the CDT will included these automatically. I recall reading that somewhere, but cannot provide a reference.
Time after time a crash of Eclipse, the VM or the computer or even just long months of development start to wear down the stability of the workspace where Eclipse stores everything.
Check the <workspace dir>\.metadata directory to get an idea of just how much Eclipse generates and stores in your workspace. Every time you add a plugin, upgrade a plugin, remove a plugin that puts and changes information in your workspace.
A proof is that this issue usually comes just after upgrading Eclipse. (In my case to Indigo).
The easiest way to fix up a dusty workspace is using the -clean command line argument to the eclipse.exe executable.
Eclipse help docs tell us what this command does:
if set to "true", any cached data used by the OSGi framework and
eclipse runtime will be wiped clean. This will clean the caches used
to store bundle dependency resolution and eclipse extension registry
data. Using this option will force eclipse to reinitialize these
caches.
There are three ways one can use the -clean command line argument:
Edit the eclipse.ini file located in your and add it as the first argument on the first line.
Edit the shortcut you use to start Eclipse and add it as the first argument.
Create a batch or shell script that calls the Eclipse executable with the -clean argument.
The advantage of step 3 is you can keep the script around and use it each time you want to clean out the workspace.
This page solved the problem to me!Hope it can help everybody else.
In the project properties, go to C/C++ Build > Tool Chain Editor, tick Display compatible toolchains only, and select Linux GCC and click Apply button.
Now if you go to C\C++ General > Paths and Symbols, you will see new list of include paths added. If you rebuild index, the error messages should go away.
The code analysis is causing this. It's not actually compiling the code but just doing some static checks for quick feedback. Unfortunately I don't know how to fix it, I just disabled it. Sorry I'm at work so I don't have CDT in front of me but I think it's something like:
Window > Preferences > C++ General > Code Analysis
Go there and un-check all the boxes to disable it.
When you create a C++ project (in my case from existing code) you have to set the 'Toolchain for Indexer Settings' to the compiler you use ('GNU Autotools Toolchains' in my case).
After this 'Path and Symbols' will show the correct path to the include files of your compiler.
The bugs will disappear.
This setting was useful only during creating the project, setting it later did not help.
In indigo 3.7.2 version (and up may be) your changes can be effect after reindexing. Eclipse ask for "reindexing". Lower versions can require a manual reindexing header tags etc.
Updated index option to active build configuration works for me,
also I removed some files from the file list of being indexed up-front,
Ok here is what worked for me:
deleted the path to the header files I created from the include path
compiled the project (obviously the compiler complains since it is missing user-defined headers)
reinserted the path to the header files I created
compiled the project again - worked perfectly
I can't explain the case :(
I am answering here because this is the closest question to my problem.
I used QT Eclipse integration with Helios (3.6.2) with no major problems. I was using mingw 4.6.2, which I had installed to c:\mingw. I wanted to upgrade to Indigo, which fixed some minor issues I was having with CDT.
However, under Indigo (3.7 SR2) Eclipse began underlining trivial functions, as being unresolved, such as:
function 'fprintf' could not be resolved
function 'memset' could not be resolved
even though #include was not underlined, could be opened, and included fprintf in the header. And even though the code itself compiled fine.
If I went back to Helios, the problems went away.
I tried reindexing, to no avail. I checked my include paths, and they were:
c:\mingw\include
C:\MinGW\lib\gcc\mingw32\4.6.2\include
At first, I had just included the first, but not the second. But then I searched for "unresolved includes", and stdio.h was including stdarg.h, which wasn't in the main include folder of mingw, so I added the second. But still, printf was not resolved, and there were no more "unresolved includes".
I created a new C++ project with one class. I added stdio.h, the paths above, and a call to fprintf. It was underlined! Even though other things from stdio were not underlined.
Now I knew that it wasn't just a Qt problem.
I worked around on this for a while before I read the bottom post here suggesting removing the include paths and compiling. I didn't believe it would work but gave it a shot. Amazingly, even though the compile failed, the error went away!
It was then that I took another look at the include paths. They had been updated by the compile step to the following:
c:/mingw/lib/gcc/mingw32/4.6.2/include-fixed
c:/mingw/include
c:/mingw/lib/gcc/mingw32/4.6.2/include
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++/backward
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++/mingw32
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++
These were marked as "built-in" values which I assume means they weren't added by me and could get updated the next time I run a build.
So, I guess the lesson is, including every single include path under mingw, even if Eclipse doesn't find it to be an unresolved include.
The next step was to put all these paths into my Qt project. Unfortunately, after doing so, the unresolved functions were still there. It appears to be some sort of bug with the Qt C/C++ include paths which are different from the CDT C/C++ include paths.
I've been trying for about 2 weeks now to get a logging library to work with. I've tried Log4cxx, Log4cpp, log4cplus and boost.log. The problem isn't that none of these work for me, it's that I can't figure out how to get them to work at all. I would really like to use log4cxx since I'm working with log4j/logback at work, but I haven't been able to get any of the libraries based on log4j to build. I've been able to build and use the boost library, but boost.log gives me all kinds of linker errors no matter what I try. If anyone could direct me to a step-by-step guide to get one of these libraries working I would greatly appreciate it. Also, I'm using eclipse as my IDE if that matters.
Did you ever get this working? Log4cxx definitely works on Win7. Maybe you could post some of your build errors. Just guessing, perhaps you didn't configure your eclipse project to link with a log4cxx static lib.
Boost.Log works for me quite well (Linux and Windows). It is not a header only library, there is a compiled part that you need to link against. See instructions here.
It also depends on other, non-header, Boost libraries:
The logging library uses several other Boost libraries that need
building too. These are Boost.Filesystem, Boost.System,
Boost.DateTime, Boost.Thread and Boost.Regex. Refer to their
documentation for detailed instructions on the building procedure.
Depending on your platform there may be pre-built versions of the Boost libraries. Otherwise building it yourself is straightforward if you follow the instructions. If you get stuck update your question with where exactly you got stuck and what you're seeing.
I'd recommend Pantheios. It takes some time to build everything when you first download - type make build test and go have lunch - and you have to select the output streams (Pantheios calls them "back ends") at link time, but for coding, it is really simple, e.g.
std::string name;
int age;
pantheios::log_DEBUG("name=", name, " age=", pantheios::integer(age));
It's designed from the ground up for speed - the age won't be converted into a string unless the "DEBUG" level is switched on - and robustness - which is why you can't pass fundamental types directly, and use "inserters" (e.g. pantheios::integer). See this recent blog post by Pantheios' author for more information.
I managed to get log4cxx to work, this was done in Visual Studios 2013 running on Windows 7 OS.
This following is what I did, step by step:
Download the log4cxx ZIP package extract its contents, http://logging.apache.org/log4cxx/download.html
Download apr and apr-util ZIP packages, http://apr.apache.org/download.cgi
Then
manually extract this zip apr-1.2.11-win32-src.zip (the
extracted folder should be named 'apr', if it is not manually rename
it)
manually extract this zip apr-util-1.2.10-win32-src.zip (the
extracted folder should be named 'apr-util', if it is not manually
rename it)
open a command prompt and run the following: cd
apache-log4cxx-0.10.0 configure (this
will execute configure.bat)
We will need to disable to use of the APR ICONV and LDAP support.
In order to do so, we will append the following files manually:
Open apr-util\include\apu.hw. Find the line starting with “#define
APU_HAVE_APR_ICONV”. Change the value to 0 and save.
Open apr-util\include\apr_ldap.hw. Find the line starting with
“#define APR_HAS_LDAP” Change the value to 0 and save.
We need to build the log4cxx.dll, to do so convert *.dsw
to *.cxproj.
Launch Visual Studio 2013 and open log4cxx.dsw.
VS will ask if you like to convert everything. Simply click Yes.
There may be some warnings in the migration report, but nothing that
should prevent the solution from opening.
> The projects xml, apr, and apr-util should build successfully.
If you try compiling the log4cxx project it will most
likely fail with hundreds of errors. This is due to a bug in VC++
which can be worked around.
Move all macros outside (above) the class they are in.
LOG4CXX_LIST_DEF macro is used to define classes. All macros reported in error C2252 will need to move out of any classes. This
may also include moving definitions which are used in the macro.
Next, change all LoggingEvent::KeySet to KeySet (this is no longer nested in a parent class)
> Following this, the log4cxx project should now compile
successfully on your machine.