I'm using MinGW 4.5.1 for compiling a client application (C++, Windows XP) utilizing the newest version of Boost 1_47. For some reason that I can't seem to determine, when I go to compile using the boost::asio::signal_set type I get a compile error (boost::asio::signal_set does not define a type), and when trying to explicitly include either of the associated signal_set headers, I get complaints of no file can be found (despite the file indeed being where expected). I have tried including files within the same level of the directory tree without issue, it only seems to hang on the signal_set.hpp file (although no complaints when using the full header asio.hpp which has it as an include). I get the same behavior when trying to use boost 1_46_1 as well.
Might anyone have any insights as to what is going on?
The issue I had was that I was not properly including the boost headers as I thought I was. Usually I have the boost installation in some directory on the hard drive, say C:\Boost\some_boost_version. Whereas I thought I was pointing to the new boost version's includes at C:\Boost\boost-1_47\boost, there was not a level inside the directory tree for \boost, everything was in C:\Boost\boost-1_47. By adding a new directory (created C:\Boost\boost-1_47\boost) and putting the includes within that, my problem was resolved. Something I overlooked when I retooled my build scripts for build the boost libraries on my machine.
Related
I'm working on a project for my cryptography course, and I've been using the Windows Subsystem for Linux. Up until recently I was able to use make -j to build my entire project quickly.
Recently, I started getting compilation errors like the one below. Strangely enough, I have no issues compiling with just make (no -j)
Because this used to work fine, I do not believe the issue has anything to do with dependencies specified in my makefiles. (Most of my code is in header files anyway because templates)
In file included from /usr/include/stdlib.h:314:0,
from /usr/include/c++/5/cstdlib:72,
from /usr/include/c++/5/ext/string_conversions.h:41,
from /usr/include/c++/5/bits/basic_string.h:5249,
from /usr/include/c++/5/string:52,
from tests/cryptomath/../../catch.hpp:207,
from tests/cryptomath/test_extgcd.cpp:2:
/usr/include/x86_64-linux-gnu/sys/types.h:219:25: fatal error: /home/ipiano/[student id]/Documents/Code/Homework/512/project/modules/module_crypto/unittests/../libclassiccrypto/affine/headers/sys/select.h: Invalid argument
It looks to me like the compiler is trying to find c++ source files (sys/select.h in this specific error) in my project directory, which implies maybe a path issue?
The only thing that I can think of that changed recently is that IT approved the Creator's Update and I installed that, but I don't know if it's relevant or not.
If anyone has seen this behavior or errors like this and knows how to resolve it, help would be appreciated.
---------EDIT---------
Was able to narrow down to a specific makefile that my main makefile was including. It was defining part of it's targets, but not all of them. Still not sure why the -j flag brought this to light, but at least it's working now
I had the same problem: my compilation failed when using "make -jN", for N>1. After some research I found the same issue described here.
The problem is likely caused by a bug introduced in DrvFs, the Windows filesystem plugin for WSL, and it happens at least in Windows builds 16273.1000, 16299.19 and 16299.64 (mine). It doesn't happen in build 16251.
According to this, the bug was fixed on Windows Build 16299.98.
Since I cannot update my Windows due the company policies and I couldn't execute this workaround, I moved my files from /mnt/c to /home/<username> and they compiled without further problems.
I've been using Boost 1.46.1 in my project until a week ago. After upgrading everything to Boost 1.55.0 I noticed that some functionality is not working as before.
My software loads configuration files which are placed via SymLinks. I'm using Microsofts mklink to do this.
I today found out that while boost::filesystem::is_empty() in version 1.46.1 was returning false for my links, it now returns true in 1.55.0. Unfortunately I'm not able to change the component which uses that code. The result is that my config files aren't loaded anymore.
Is there a way to create links in a way that Boost is able to recognize them?
If I get access to the code: How would I need to change it to work again?
UPDATE:
Some more information in response to the comments:
The SymLink is valid, there is a file linked to it
The file linked to the SymLink is not empty, it is a valid config file which worked before
The user has permissions to the SymLink and to the linked file
I'm able to do an fopen on that file and read its contents
UPDATE2:
I just created a Github project with everything included to recreate the issue. I used VS 2013 Express to compile the program:
GitHub Project - BoostSymLinkError
main.cpp
The problem is that older versions of Boost filesystem (V2) on Windows used VC++'s stat() function to obtain the information on the target file, and that function followed symlinks.
Newer versions of the filesystem library (V3) use the the Win32 GetFileAttributesExW() API, and it doesn't follow symlinks, so the size of the object specified by the path gets returned as 0.
It looks like filesystem V3 was made the default in Boost 1.46 and V2 was removed from the library in 1.48. One possible fix for your problem is to move back to a version of Boost before 1.48 (and possibly build the libraries with the BOOST_FILESYSTEM_VERSION macro set to 2).
I have opened a bug against this and the bug report includes a patch against libs/filesystem/src/operations.cpp that fixes the problem:
https://svn.boost.org/trac/boost/ticket/9824
Keep in mind that the patch I submitted in the bug report hasn't had much testing (for example, it needs to be tested against other versions of Windows, with the MinGW toolchain, with paths that include characters outside the ASCII range, directories as targets, and probably a number of other things I haven't thought of). However, if you want to continue using a recent Boost release, you're welcome to patch your local Boost libs to see if it solves the problem for you.
I originally installed boost per the instructions at http://www.boost.org/doc/libs/1_55_0/doc/html/bbv2/installation.html
I transferred most of my Windows user profile to a new computer, which contained a folder called CodeLibs. This folder is where I originally installed boost (in place of PREFIX in above documentation).
I compiled a project that uses the serialization library, and I didn't receive any errors.
My question is, is there any reason to go through the documented installation process again or is the above directory transfer sufficient?
Thanks in advance.
Copying should be fine, so long as the target architecture is the same.
Boost doesn't need to be "installed" in the typical way. There are no registry settigs to set, no COM servers to install, no daemons to set up. Nothing like that.
The install process you went through originally mostly consisted of compiling code. That code, once compiled, was then copied to some destination folder and some environment variables might have been updated.
None of this is truly necessary, but once you get the code on your target machine you might have to tweak a few paths etc so that the compiler can find the headers and libs (if any libs are needed), and executables can find the shared libraries.
Assuming you have a high level of proficiency with such things -- as is suggested by the fact that you were able to install it the first time at all -- I'm sure none of this will be a major challenge for you.
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 have the following Problem.
I started to use the boost library version 1.40, for unit testing.
Since some other people working on the project and not all of them are using eclipse, the program has to be compilable with a makefile. So we used cmake to generate one.
The good thing is, the test is building and working perfectly fine.
But the problem is, when using eclipse (created a c++ makefile project), it complains about several syntax errors (in the sourcecode view).
Something like:
BOOST_AUTO_TEST_CASE( my_test )
{ some code }
will be detected as a syntax error by eclipse. It is really annoying having all these error messages in the IDE. Since after the first line nearly every line in the some code block is marked as having syntax errors as well.
So here is what i tried already:
I added `/usr/include/boost/` to the GNU C++ path options. (properties->C/C++ General->Path and Symbols->Path). This works normally for other external libs that are included by FindPkgConfig in the cmake file. So that the auto completion in eclipse can find the correct classes and function names.
Same way included `/usr/include/boost/test/` directly.
Adding `/usr/lib/libboost_unit_test_framework.so.1.40.0` to the Libraries list.
Adding `/usr/lib` to the Library Paths.
So anyone has a hint how to teach eclipse that the syntax of the boost Macros is correct??
Update:
I forgot:
System is Linux and Eclipse Version is 3.6.1, CDT Version is:
Version: 1.0.0.201009141542
Build id: 201009141542
I don't have a solution but maybe a hint.
I had a similar setup and it worked perfectly until...
the only relevant change I remember is that I changed the name of a test suite.
So (probably) after that, the syntax highlighting went crazy.
I tried indexing and refreshing but it didn't help.
I can't even see the macro expansion because the syntax error prevents it from popping up.
My guess is — still — some indexing issue, because it worked before and I didn't change any include paths. It compiles without problems, but it's urinating these yellow syntax error markers all over the document, which is really, really annoying.
However, it's probably not a path issue because it worked for me before.
I just did this myself using Eclipse Helios, and it does indeed work for me...
Shouldnt you add /usr/include and not /usr/include/boost, since boost is part of the include path used in your program?
For example <boost/unit_test.hpp> is simply <unit_test.hpp> if you include the boost folder aswell..
This is what I have added under GNU c++ include directories:
/usr/local/include //this is where I store the boost folder
/usr/include/c++/4.5.2 //This was needed since not even <map>, <vector> etc would resolve in eclipse.
Intellisense and autocompletion for C++ are pretty much impossible to get right in all cases. If the many macros used in Boost.Test confuse Eclipse, then perhaps you should find a cleaner unit test library. I can recommend Catch, which has a cleaner and friendlier syntax, is header-only so it's much easier to set up, and doesn't rely on macros. It is under active development by another SO user.
I had this problem as well (but on a Mac system). Once I added the boost path to GNU C++ path options, I restarted my operating system and Eclipse doesn't tag BOOST_AUTO_TEST_SUITE as an error any more.