"No such file" Include issue with Boost dynamic_bitset - c++

I'm trying to use Boost's Dynamic_bitset class for a project, and I (believe I) have taken whichever subset of files I needed from the complete library. Now I'm doing an
#include "boost/dynamic_bitset.hpp" inside my manager.cpp file, and when compiling I get this:
In file included from manager.cpp:4:0:
boost/dynamic_bitset.hpp:15:51: fatal error: boost/dynamic_bitset/dynamic_bitset.hpp: No such file or directory
The file ierarchy inside the project folder goes like this:
proj/extras.h
proj/Makefile~
proj/manager.cpp
proj/boost
proj/boost/limits.hpp
proj/boost/dynamic_bitset.hpp
proj/boost/mpl
proj/boost/mpl/if.hpp
proj/boost/mpl/has_xxx.hpp
proj/boost/iterator.hpp
proj/boost/static_assert.hpp
proj/boost/dynamic_bitset
proj/boost/dynamic_bitset/dynamic_bitset.hpp
proj/boost/dynamic_bitset/config.hpp
proj/boost/config
proj/boost/config/select_platform_config.hpp
proj/boost/config/select_compiler_config.hpp
proj/boost/config/user.hpp
proj/boost/config/suffix.hpp
proj/boost/config/select_stdlib_config.hpp
proj/boost/dynamic_bitset_fwd.hpp
proj/boost/config.hpp
proj/boost/type_traits
proj/boost/type_traits/is_same.hpp
proj/boost/type_traits/is_pointer.hpp
proj/boost/type_traits/remove_pointer.hpp
proj/boost/type_traits/remove_const.hpp
proj/boost/type_traits/is_base_and_derived.hpp
proj/boost/type_traits/detail
proj/boost/type_traits/detail/bool_trait_def.hpp
proj/boost/type_traits/detail/yes_no_type.hpp
proj/boost/pending
proj/boost/pending/integer_log2.hpp
proj/boost/detail
proj/boost/detail/limits.hpp
proj/boost/detail/dynamic_bitset.hpp
proj/boost/detail/workaround.hpp
proj/boost/lowest_bit.hpp
proj/Makefile
proj/generator.cpp~
proj/generator.cpp
This same project compiles fine on my university's linux systems(g++ 4.2.4 there but I doubt it matters), but fails to do so (with the above error) on my Ubuntu laptop. Why isn't it finding the file since it evidently exists?
All my includes are as such:
#include <cstdlib>
#include <cstdio>
#include <iostream>
#include "boost/dynamic_bitset.hpp"
#include <cmath>
#include <list>
#include <unistd.h>
#include <sys/sem.h>
#include <sys/shm.h>
#include <errno.h>
#include <wait.h>
#include <time.h>
#include "extras.h"
compilation is done simply with
g++ -o manager manager.c
or
g++ -Iboost -o manager manager.c
if I want to explicitely include the (local..) folder

-I .
At least if you are compiling in the same directory that contains boost.
You wrote -Iboost and #include "boost/…". So it looks in ./boost if there is a boost subdirectory.

Related

Syntax highlighting for llvm c++ api in clion

Right now I'm quite extensively using the C++-Api for LLVM IR. I'm using CLion as my IDE and im building and linking the project via a Makefile.
The includes look like the following
#include "llvm/IR/BasicBlock.h"
#include "llvm/IR/Constants.h"
#include "llvm/IR/DerivedTypes.h"
#include "llvm/IR/Function.h"
#include "llvm/IR/Instructions.h"
#include "llvm/IR/IRBuilder.h"
#include "llvm/IR/LLVMContext.h"
#include "llvm/IR/LegacyPassManager.h"
#include "llvm/IR/Module.h"
#include "llvm/IR/Type.h"
The problem now is that I don't have any syntax highlighting for the things coming from the llvm headers. How do I enable that.

Error in Compiling OpenGL code under Windows

I am trying to compile an OpenGL program.
This is the portion of the code with all the includes:
#include <stdio.h>
#include <assert.h>
#include <stdlib.h>
#include <GL/glew.h>
#include <GL/glut.h>
// Usage of degrees is deprecated. Use radians for glm functions.
#define GLM_FORCE_RADIANS
#include <glm/glm.hpp>
#include <glm/gtc/matrix_transform.hpp>
#include "shaders.h"
The file i am trying to run is called mytest1.cpp and i also have shaders.h in the same directory.
In the same directory i have a folder called 'include' And inside two subfolders called 'GL' and 'glm' with all the files inside that are required from the program.
So i go to the directory of the mytest1.cpp and i type g++ mytest1.cpp and i get the error:
mytest1.cpp:14:21: fatal error: GL/glew.h: No such file or directory
#include <GL/glew.h>
^
compilation terminated.
Why does this happen? I also tried to place the 'GL' folder in the root directory and i got the same error

include <Eigen/Dense> succeed, include <Eigen> failed

My question is similar to this 5 years old question.
I can successfully compile it if I use the following code:
#include <Eigen/Dense>
#include <iostream>
//#include <boost/serialization/array_wrapper.hpp>
#include <boost/date_time/gregorian/gregorian.hpp>
int main(){
std::cout<<"asfserea"<<std::endl;
boost::gregorian::date d(boost::gregorian::day_clock::local_day());
std::cout << d.year() << d.month() <<d.day() << std::endl;
return 0;
}
But I got errors after I changed annotation from #include <Eigen/Dense> to #include <Eigen>, from #include <boost/date_time...> to #include <boost/serialization...>:
File you are looking for is <Eigen/Eigen>. If you want to include <Eigen>, you should add correct folder to your include path.
For array_wrapper.hpp, you need newer version of Boost. At least version 1.67.0 has this file.
When you #include <Eigen>, your compiler looks at the directories that you have told it about, for a file named Eigen. It only finds a folder named Eigen, and within that folder there are files Eigen and Dense. It does not look inside that folder.
If you change your compilers parameters to include the Eigen folder (rather than it's parent), you can #include <Eigen> and #include <Dense>. Alternatively, you can keep your include directories as they are, and prepend Eigen/ to all the Eigen includes

C++ program compiling without functional header

As per CPP Doc, std::greater is defined in <functional> header but my C++ program using std::greater is compiling with TDM-GCC-64 5.1.0 and running with only the following includes :
#include <cmath>
#include <cstdio>
#include <vector>
#include <iostream>
#include <algorithm>
#include <unordered_map>
It could be because <algorithm> automatically includes <functional> but since this is not mentioned in the doc, I was wondering is there a way to know this before hand ?
Just to close the topic, the conclusion is that this is implementation dependent and all the necessary headers should be included for portability.

Linux: Conflicts using inotify with fcntl

I'm having a strange linking issue after I included inotify in my program to monitor changes to a filesystem. The project includes <fcntl.h> in many other source files. However, when I include <sys/inotify.h> in the source file which is doing the directory monitoring, I get this error:
/usr/include/fcntl.h:30:1: error: expected initializer before ‘extern’
__BEGIN_DECLS
My project uses CMake, although that doesn't seem to be relevant for finding inotify. It IS finding the inotify declarations to my knowledge, since when I included , it threw an error that inotify_init() and the other functions I used were not defined. Inotify includes fcntl and is partially built on top of some of the functionality there, so my first thought was that it's importing a different version of fcntl than the rest of my program.
In ObjectManager.h:
#ifndef MANAGE_OBJECT_H
#define MANAGE_OBJECT_H
#include "config.h"
//includes all lua headers under extern 'C'
#include <lua.hpp>
#include <list>
#include <unordered_map>
#include <pthread.h>
class ObjectManager //...
The only thing that changed was ObjectManager.cc, with the addition of sys/notify and the implementation of the watcher (not included because this is a linking issue):
#include "config.h"
#include "ObjectManager.h"
#include "Control.h"
#ifdef OBJECT_MANAGER_ENABLED
#include <string.h>
#include <stdio.h>
#include <dirent.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <vector>
#include <unistd.h>
#include <fstream>
#include <sys/inotify.h>
//... inotify implementation
Where Control.h declares #include <fcntl.h>.
This is the closest issue I found, related to some problems in the implementation of different fcntl headers for userspace usage. https://lkml.org/lkml/2008/9/16/98
The same problem occurs on Linux 2.6 running on Centos 6 and Linux 4.0 running on Centos 7.
Any ideas on what is causing this error and how to successfully include inotify?
Resolution: A function definition lacked a semicolon at the END of ObjectManager.h right before a #endif, and the resulting GCC error that propagated through the next includes in a complicated manner, resulting in a strange preprocessor error in fcntl.h.