I am following the course "Introduction to Deep Learning with Xilinx SoCs Technical Training Course" for the Ultra96v2 board and reached Lab No. 5.
I am able to follow along until I am supposed to build the project in the SDK.
It fails and tells me errors like these:
15:49:06 **** Incremental Build of configuration Debug for project mnist_file_io ****
make all
Building file: ../src/mnist_file_io.cc
Invoking: ARM v8 Linux g++ compiler
aarch64-linux-gnu-g++ -Wall -O0 -g3 -I/media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/training/AvnetTTC/DPU/U96AI_student_20200115/U96AI/2018_3/work/lab5/workspace/ExtraIncludes -I/usr/include -c -fmessage-length=0 -MT"src/mnist_file_io.o" --sysroot=YSROOT -MMD -MP -MF"src/mnist_file_io.d" -MT"src/mnist_file_io.o" -o "src/mnist_file_io.o" "../src/mnist_file_io.cc"
In file included from ../src/mnist_file_io.cc:9:0:
/tools/Xilinx/SDK/2018.3/gnu/aarch64/lin/aarch64-linux/aarch64-linux-gnu/include/c++/7.3.1/cmath:45:15: fatal error: math.h: No such file or directory
#include_next <math.h>
^~~~~~~~
compilation terminated.
src/subdir.mk:21: recipe for target 'src/mnist_file_io.o' failed
make: *** [src/mnist_file_io.o] Error 1
It doesnt find the header file, although it is included in the paths which were provided by the tutorial as well as by me. Actually, two additional files haven't been found:
#include <opencv2/opencv.hpp>
#include <dnndk/dnndk.h>
I was able to include them by picking them by hand from the directories where they were in and adding them to an extra directory in which the Xilinx SDK should search for headers.
But this brings up the question: Why aren't they found in the first place? After correct installation and following the instructions in the above mentioned tutorial, shouldn't I be all set up to just build it?
Actually, by using the installer on the Xilinx Download website (Xilinx_SDK_2018.3_1207_2324_Lin64.bin), the SDK didn't start because there were some files missing for the SDK program (eclipse and some other stuff). So it just started once I copied those files from the other installation (Vivado, etc.). Isn't this also supposed to work just out of the box? Reinstalling, etc. didn't work unfortunately.
So I guess one question that crystallizes here is: Is there a possibility to give Eclipse/Xilinx SDK a path to a directory for all required standard header files and it searches in them? Because in some standard headers, they include other headers, which in turn aren't found by the Xilinx SDK. And will that fix my issues?
Funnily enough, when I use the Ctrl+Click action to jump from header to header, all headers are found and it's no problem. It's only in the build process where embedded further headers aren't found anymore. Also, when I change the #include_next to #include, the whole thing starts working again. The same with changing #include <header> to #include "header.h". Then it works. But that can't be the solution, changing every header that throws an error, since it was generated like this for a reason, right?
This is really annoying and disrupts any workflow.
Is there someone who had this problem as well and may help me?
I am using Ubuntu 16.04 and the Ultra96v2 board.
Update
What I've investigated so far with no avail:
https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/993711/cc3235sf-why-is-ccs-eclipse-unable-to-see-the-c-standard-header-files
Eclipse can't find header file, even though include paths are set
Where are the headers of the C++ standard library
https://www.eclipse.org/forums/index.php/t/1088833/
I have included the path for my C++ gcc standard library as a path in which Eclipse/the Xilinx IDE is supposed to search for headers, but the headers inside the files aren't being found.
Update 2
Here you can see where the problem starts. It's really weird, since everything is auto-generated and thus should just work, especially since those are predefined headers and sources, which haven't been altered by me.
Here, you can see that I included the usual standard header location in the inclusion paths, so the files in question should be found.
Related
Completely new project is totally fine, but I found pretty old opensource project and want to compile it. Basically, error appears when including headers like iostream or algorythm.
My environment looks like the following:
MacOS 10.15.4
Clang 11.0.3
Cmake 3.16.5
Tools and headers are installed here /Library/Developer/CommandLineTools/usr/bin
Project uses cotire 1.8.0
IDE - CLion
In general, project consists of 30+ sub-projects some are C some C++. Only those in C can be built.
I've been trying a lot of stuff: setting target version for Cmake, setting paths where to look for headers manually (in Cmake files). Re-installing developer tools does not help as well.
Please, see original error message:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/iostream:37:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/ios:214:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/iosfwd:95:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/wchar.h:118:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/wchar.h:92:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/_wctype.h:42:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/__wctype.h:62:
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/_types/_wctype_t.h:32:9: error: unknown type name '__darwin_wctype_t'
typedef __darwin_wctype_t wctype_t;
UPDATE 1
I've moved a bit forward, and figured out that stdafx.h cannot even include iostream. So I will check all include paths.
There was an issue with includes. Project has its own _types.h, and there is one in system. Project's variant was included first and system's one was ignored. Obviously, this leads to such cryptic messages.
This is a root cause.Clang's documentation says I need to use -isysroot to explicitly set system's headers root and this will prevent matching project's header first, but it doesn't work for me. Temporarily, I changed project's header name(types.h) and it worked well(without underscore it is no longer considered as a system header), in the meantime I will try to fix it properly.
I've found that a small C++ project, with no dependencies, won't compile under Cygwin with either GCC or Clang. Under Ubuntu there are no problems; and I've been working with this code for a couple of years. I'll introduce a MWE.
The problem arises when including a header in a subdirectory, which itself includes another header, found in that same subdirectory, but specified with the subdirectory in the path provided to the include directive. Executing the following commands can replicate the error:
mkdir foo
echo \#include \"foo/includes.hpp\" > inc.hpp
echo \#include \"foo/bar.hpp\" > foo/includes.hpp
touch foo/bar.hpp
g++ -c inc.hpp
On 64-bit Ubuntu 18.10, the final GCC (or Clang) invocation will produce no errors. On 64-bit Cygwin under Windows 10, the following error message is displayed.
In file included from inc.hpp:1:0:
foo/includes.hpp:1:10: fatal error: foo/bar.hpp: No such file or directory
#include "foo/bar.hpp"
^~~~~~~~~~~~~
compilation terminated.
Can anyone shed some light on the issue? (By the way, I myself do well understand how to properly include header files - this is about the difference between Cygwin and Ubuntu.)
foo/includes.hppshould have local includes if you use "".
That would be:
#include "bar.hpp"
The specification for what paths are used for searching headers is custom for all compilers, although includes with "" should be considered as local for the file where you have the include, not the one that you are compiling.
Basically, it's:
look in the current folder of the current header being processed for a file with that name
use the same paths as <>after
Of course, as I've said, this could change for a new compiler one day. But it is quite safe to assume that this is the behavior for all compilers (What is the difference between #include <filename> and #include "filename"?).
I am trying to cross-compile OpenImageIO for 64-bit Windows on Fedora 26 using MinGW. After using yum to retrieve the mingw versions of the dependencies, I ran mingw64-cmake followed by make. However, right away I receive a compile error about stdlib.h not being found.
[ 0%] Built target CopyFiles
[ 0%] Building CXX object src/libutil/CMakeFiles/OpenImageIO_Util.dir/argparse.cpp.obj
In file included from .../oiio/src/libutil/argparse.cpp:36:0:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
#include_next <stdlib.h>
^~~~~~~~~~
compilation terminated.
I have confirmed that stdlib.h is found at least in /usr/include/ and in /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/ where the file giving the compiler error also is located.
Why do I still receive the error stdlib.h: No such file or directory?
Update:
I did additional research and learned the following: The preprocessor directive #include_next behaves like the #include directive, except that it specifically excludes the directory of the including file from the paths to be searched for the named file.
This would explain why cstdlib does not find stdlib.h from the same folder. But cstdlib is part of MinGW and not any part of the code I am trying to compile. So I still have no idea what is wrong here or how to fix this error.
Edit: Here is the compiler version info in case it is of any use: https://pastebin.com/PZiXS2fg. This is a fresh install so there shouldn't be anything unusual there, though.
I solved it, i can compile again.
The solution (for me) is add to path the variable CPLUS_INCLUDE_PATH and set it to the MinGW c++ include directory, for me: C:\MinGW\lib\gcc\mingw32\6.3.0\include\c++.
I hope it works for you too.
The use of #include_next appears to cause lots of issues based on my Googling. Try directly including stdlib.h using the following syntax:
-isystem /usr/x86_64-w64-ming32/sys-root/mingw/include/c++
This syntax was added in gcc 6.0 to solve issues with third-party libraries. See here for the approach and reasoning.
Edit: Changed answer to reflect new information about gcc wrapper_headers and #include_next
This is my first stab at C++, also I know that the question is broad but I have a specific example that I'm working with so hopefully that will narrow everything down a bit.
I'm basically attempting to compile a C++ game manually in Linux (Ubuntu 14.04). The source code I am attempting to compile is located in this directory: https://github.com/akadmc/SmashBattle/tree/master/battle.
I'm CD'ing into the battle directory and, perhaps naively running
gcc *.cpp
I started seeing multiple issues as such:
compilation terminated.HealthPowerUp.cpp:1:21:
fatal error: SDL/SDL.h: No such file or directory #include "SDL/SDL.h"
and
compilation terminated.LaserBeamPowerUp.cpp:1:21:
fatal error: SDL/SDL.h: No such file or directory #include <SDL/SDL.h>
After researching header file includes I concluded that includes without <>'s are basically just relative paths to include a header file, and that when they are wrapped in <>'s they can either lookup the file through a listing of directories specified in an enviornment variable, or a command line option.
So my first question is, is there any reason the developer used
#include "SDL/SDL.h
AND
#include <SDL/SDL.h>
in different files? There was no SDL directory in the source code...
After realizing that SDL was missing from the source code / environment in one way or another I did tinkering. I was pretty confused (and still am) because I downloaded the SDL source files, didn't see any header files, ended up building a version of SDL by using cmake, and then build. I realized afterwards that I just made a local executable and didn't yield any header files. Then I realized that I just needed the development library, downloaded that, and put higher in the directory tree and then included it at compile with
c++ *.cpp -I $HOME/Desktop/smashProject/source/
Afterwards, the previous header file errors went away - but I started getting errors like the following:
Text.cpp:(.text+0x17): undefined reference to `SDL_RWFromFile'
Text.cpp:(.text+0x24): undefined reference to `SDL_LoadBMP_RW'
Text.cpp:(.text+0x34): undefined reference to `SDL_DisplayFormat'
And so on. Am I generally headed in the right path or do I have some misunderstanding about compiling, including development libraries, etc? Also I've read the the order of the compilation matters, and I'm not using any order + the developer didn't put a makefile in the source code or anything. I'm generally just confused as to how I should be doing this. Any help would be greatly appreciated.
Yes, you are on the right track. However, now you need to have a linkage to the SDL libraries. The -I just includes an extra library path but you have to actually link your assembly to the SDL files.
See this stack overflow question for more information.
How to compile an example SDL program written in C?
OS: Ubuntu 12.04 64-bit
I've installed Bullet Physics from source, and am attempting to
#include <btBulletDynamicsCommon.h> from a source file.
When I compile the source file, I get the following error...
error: btBulletDynamicsCommon.h: No such file or directory
The following is an excerpt from my terminal...
uberblah#uberblah-N80Vm:~$ locate btBulletDynamicsCommon.h
/home/uberblah/lib/cpp/Bullet/bullet-2.81-rev2613/src/btBulletDynamicsCommon.h
/usr/local/include/bullet/btBulletDynamicsCommon.h
/usr/local/include/bullet/BulletDynamics/btBulletDynamicsCommon.h
Is there a particular reason the compiler wouldn't be finding the header?
It should be noted that I am using Code::Blocks to do the building, although the same error is received if I try to put that include in a source file and then compile it using a my own Makefile (I don't actually reference any of the functions from the header, so there's no need to link the libraries).
Add "/usr/local/include" to 'Settings > Compiler and Debugger > Global compiler settings (on left) > Search directories' and use
#include <bullet/btBulletDynamicsCommon.h>
This way when you want to use other headers in /usr/local/include, you don't have to keep adding the individual directories.