I can't convince avr-gcc on windows to include a *.h file from another directory:
>avr-gcc -Wa,-gdwarf2 -x assembler-with-cpp -c -mmcu=atmega256rfr2 halW1.S
C:\Users\me\AppData\Local\Temp\ccjzoYpN.s: Assembler messages:
C:\Users\me\AppData\Local\Temp\ccjzoYpN.s:6: Error: can't open halGccD.h for reading: No such file or directory
The required file is one up level in ../include folder
(this is the BitCloud stack provided by Atmel itself)
I tried as Atmel Studio does to pass include folder:
>avr-gcc -Wa,-gdwarf2 -x assembler-with-cpp -c -mmcu=atmega256rfr2 halW1.S -I "..\include"
But seems that avr-gcc assembler ignores the -I option. I tried with relative, absolute, even put that path in global PATH.
If I copy required *.h in the same folder where *.S file resides, it's working.
What is wrong?
Ok, found'it by mistake.
In case anyone needs, -I is not working alone for assembly files. When using avr-gcc as assembler, explicit assembler (-Wa) or linker (-Wl) directives must precede others. Such as:
-Wa,-I"..\..\path_to_h"
Also pay attention to backslash (not slash)... the old windows problem.
Seems that avr-gcc should parse correctly, but is not.
Related
I'm trying to understand the following line in a Makefile.in file:
CXXFLAGS += -O3 -DNDEBUG -std=c++11 -Wno-deprecated-declarations -Isrc -I #mathinc#
I know the -I flag adds a directory to the list of places where the compiler will search for included files but what does #mathinc# mean?
Note that the file is called Makefile.in -- this signifies that it is input to another file (or transformation).
In short, configure will run and determine, say, where the relevant include files are for #mathinc -- likely some math headers. After you run configure it will produce Makefile (no trailing .in) based on what it finds. Do inspect that file.
configure scripts are created in a system called autoconf which, like all build systems, has its fans and its haters. There are some decent tutorials as for example this one.
It would be helpful if you could provide some guidance on how to compile c++ source code files in an Ubuntu environment, using the MATLAB Engine with g++.
I assume that you want to know the procedure for compiling the c++ code (which calls MATLAB engine) using g++ from Linux Terminal. To do so, follow the steps below:
Include following paths in PATH variable:
a) Location of MATLAB i.e. $matlabroot/bin
b) $matlabroot/sys/os
You can do this by using the command
'setenv PATH $matlabroot/bin:$matlabroot/sys/os:$PATH ' .
In the command prompt, navigate to the directory where the cpp code is located using cd command. For instance, if you are compiling engdemo.cpp, you need to navigate to $matlabroot/extern/examples/eng_mat/engdemo.cpp
You need to call the compiler with required include files and libraries. For this you can use -I and -L switches for that. Note that the order is important. So you need to use the command as below:
g++ engdemo.cpp -I "$matlabroot/extern/include" -L "$matlabroot/bin/glnxa64" -leng -lmat -lmex -lut -o engdemo.o
The above command will generate an object file engdemo.o. To execute this, use the command ./engdemo.o
You can refer to the document at http://www.umiacs.umd.edu/~jsp/Downloads/MatlabEngine/MatlabEngine.pdf for more help regarding C++ and MATLAB.
The compilation process in C/C++ is divided in two phases:
First, the compilation where source code is transformed into machines code with multiples object files (.o or .obj).
Then, the link to transform object files into a single executable file (.dll or .exe).
C/C++ programs that run matlab engine need three things:
1> A compiler that is compatible with matlab engine.
2> Reference to API header files('.h' for c or '.hpp' for c++) for compilation.
3> Reference to the libraries('.lib' for windows,'.so' for linux) for external symbol link.
You can see comptatible linux based system compiler here.
The GCC C/C++ 4.9.x is compatible so you can use g++.
As this pdf suggested, the API header files should be there $matlabroot/extern/include and the .so files should be in $matlabroot/
bin/glnax64 where $matlabroot is your matlab install folder
Set up Environment variables
Open your temnial with ctrl + alt + T and type :
setenv PATH $matlabroot/bin:$matlabroot/sys/os:$PATH
You can then go to the folder where source file is located, let's say $matlabroot/extern/examples/eng_mat/ with the following command :
cd $matlabroot/extern/examples/eng_mat/
You need to do the compilation with :
g++ -c engDemo.cpp -I '$matlabroot/extern/include' -leng -lmat -lmex -lut
After that, a file named engDemo.o should be created.
The -leng -lmat -lmex -lut options are probably needed among other things because of the usage of the matlab interpreter that should be located in $matlabroot/bin
And the external symbol link with :
g++ -o engDemo -L '$matlabroot/bin/glnax64'
Be careful as this path sugested that you are on a x64 architecture machine, if you are not,the path might be slightly different.
Then you can execute your file just by doing ./engDemo
I can't install the matlab engine on the laptot I am using so I'm unable to test the instruction I gave you but It should be done this way.
Hope it helps !!
I have a file cpp-options.txt in which I have written every compiler option I use to compile my C++ programs.
I have made an alias g+ as g++ #/path/to/cpp-options.txt $* , so that whenever I invoked g+ prog.cpp, from anywhere on my computer, the program is compiled with all the compiler options from that file.
Now I want to add another option which includes a header file header.h in the options file. This file is always kept on the same directory as the cpp-options.txt file.
So, now the cpp-options.txt file looks like this -:
-Wall -Wextra.....
-include /path/to/header.h
Now, this setup works on Windows perfectly, but wont work on Linux, as the absolute path to the options file on Linux would be something like this -:
/mnt/media......../absolute/path/to/header.h
So, the compiler would complain about the absence of any such file on Linux.
Now I am aware of one solution of this problem, that is to include the folder in which these two files are kept in the PATH environment variable on both the Operating Systems and then simply writing -:
-Wall -Wextra.....
-include header.h
However, I dont want to pollute the PATH variables.
Is there any other way of accomplishing this ?
The best I could do was to create another common file cpp-options-common.txt which contained only the the compiler options (-Wall, -Wextra, -std=c++14 etc), and shift the -include /path/to/header.h statement to the cpp-options.txt file.
Also, I imported the cpp-options-common.txt file into the cpp-options.txt file by using the # GCC compiler directive.
My final configuration -:
cpp-options-common.txt -: ( located in the Windows partition )
-Wall -Wextra -Wfatal-errors ...
On Windows -:
cpp-options.txt -:
#path/to/cpp-options-common.txt
-include path/to/header.h
Linux -:
cpp-options.txt -:
#/media/Data/path/to/cpp-options-common.txt
-include /media/Data/path/to/header.h
I am in the App folder of my project. I run the following command to compile character.cpp
g++ -Wall -std=c++11 -I../App -c Character/character.cpp -o Obj/character.o
which is in App/Character directory. character.cpp has the following include
#include "Inventory/inventory.hpp"
where the folder of inventory.cpp is App/Inventory.
I thought because I am running the g++ command from App, the default include path would start from App and therefore I wouldn't need to have the -I../App part of the command. To me this seems to be saying "move one level higher than App then move into App and include from there" which seems redundant but without that line it doesn't work.
Can anyone explain why?
EDIT
Looking at it again and some more documentation, I believe that if no -I path is specified, g++ will look in its default directories and then all other includes (like the one I have causing problems) are relative to the file that includes them. So I have to add the -I part to say "look in the App directory too" and since it doesn't like just -I, I have to use ../App because that is equivalent to not moving at all. Can anyone confirm if this is at all accurate?
You can use -I. for searching headers from the current directory, instead of -I../App.
This include preprocessor directive
#include "Inventory/inventory.hpp"
forces gcc (g++ or cpp) to search the header not from the current path (App/), but from directory of your source file (App/Character):
/root/App# strace -f g++ -c -H ./Character/character.cpp 2>&1 |grep Inven
[pid 31316] read(3, "#include \"Inventory/inventory.hp"..., 35) = 35
[pid 31316] stat64("./Character/Inventory/inventory.hpp.gch", 0xbfffe6a4) = -1 ENOENT (No such file or directory)
[pid 31316] open("./Character/Inventory/inventory.hpp", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
..then try system directories
This is documented here: https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html
GCC looks for headers requested with #include "file" first in the directory containing the current file
This behavior can be not fixed in the Language standard (ISO C), and is implementation-defined (as commented by Richard Corden and answered by piCookie in What is the difference between #include <filename> and #include "filename"?):
specified sequence between the " delimiters. The named source file is searched for in an implementation-defined manner.
But this is the way the C compiler should work under Unix, according to Posix, aka The Open Group Base Specifications Issue 7:
Thus, headers whose names are enclosed in double-quotes ( "" ) shall be searched for first in the directory of the file with the #include line, then in directories named in -I options, and last in the usual places. For headers whose names are enclosed in angle brackets ( "<>" ), the header shall be searched for only in directories named in -I options and then in the usual places. Directories named in -I options shall be searched in the order specified.
It is useful when your current directory is far from the source directory (this is the recommended way in autotools/autoconf: do mkdir build_dir5;cd build_dir5; /path/to/original/source_dir/configure --options; then make - this will not change source dir and will not generate lot of file in it; you can do several build with single copy of source).
When you start g++ from the App directory with -I. (or with -I../App or -I/full_path/to/App), gcc (g++) will find the Inventory. I added warning to the header to see when it will be included; and -H option of gcc/g++ prints all included headers with pathes:
/root/App# cat Inventory/inventory.hpp
#warning "Inventory/inventory.h included"
/root/App# cat Character/character.cpp
#include "Inventory/inventory.hpp"
/root/App# g++ -I. ./Character/character.cpp -H -c
. ./Inventory/inventory.hpp
In file included from ./Character/character.cpp:1:
./Inventory/inventory.hpp:1:2: warning: #warning "Inventory/inventory.h included"
I have 2 different g++ compilers on my computer:
one in the standard directory (C:\MinGW),
and one is a portable distribution.
Now I'm trying to link a c++ project.
The problem is, it is linked against boost libraries
compiled with the portable distribution of g++. The standard
installation directory is ofcourse included in the PATH environment
variable. So when I try to compile my project it will produce linker errors.
I tried to create a batch file which added the portable version's directory at the beginning of the PATH variable. With no luck. Maybe some one can help me out?
#echo off
set PATH=%~dp0..\c++\compiler\bin;%PATH%
REM cd /d "%~dp0"
..\c++\compiler\bin\g++ main.cpp ^
-std=c++0x -static-libgcc -static-libstdc++ ^
-I"../c++/include" ^
-L"../c++/lib" ^
-l"boost_serialization-mgw46-mt-1_52" ^
-l"boost_system-mgw46-mt-1_52" ^
-o output.exe -W -O2
pause
Note: I used "..\c++\compiler\bin\" befor the g++ command because I wanted to be sure it it used the right path, but ofcourse it doesn't work the way I expected.
Solved it by recompiling boost with the installed version of GCC.