I am looking for the clang equivalent of the cl command /FC. I need full paths for my build tool to parse out and open the code files with the errors.
https://msdn.microsoft.com/en-us/library/027c4t2s.aspx
CFLAGS+= -fdiagnostics-absolute-paths
You need to specify a fully-qualified or relative path to the file on the command-line instead of only passing in the filename. In the following example the debugger won't know where to find "blah.cc" because I compiled by specifying only the filename:
~ pwd
/mnt/scratch/myproject/src
~ clang++ blah.cc -c -o /mnt/scratch/myproject/build/blah.o
~ cd ../build
~ clang++ *.o -o myprogram
... however, if instead I'd done this:
~ pwd
/mnt/scratch/myproject
~ clang++ /mnt/scratch/myproject/src/blah.cc -c -o /mnt/scratch/myproject/build/blah.o
# or:
~ clang++ src/blah.cc -c -o build/blah.o
# ...
... then it embeds the fully-qualified or relative path into the debug sections.
If you use a partially qualified path, you'll have to tell GDB where to look for the code. You can look at the documentation for it here, though two gdb commands that may be helpful:
# This will cause gdb to look in "path2" instead of "path1"
(gdb) set substitute-path path1 path2
# This allows you to give a list of directories to search for your source.
# note that if you give relative paths on the command-line, it'll concatenate
# these paths and the relative path used at compile-time.
(gdb) set directories path [path ...]
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.
I just started learning C++, and I've been trying to run my program from the command line using:
g++ helloworld.cpp
which works, then I typed
./a.out
then it returns the error '.' is not recognized as an internal or external command.
I tried doing a.out, but it returns:
'a.out' is not recognized as an internal or external command.
I'm pretty new to the command line so it might be quite a novice problem. I'm using the gnu gcc compiler. My code is just a simple code for printing "helloworld", and it doesn't seem to be a problem with the code since the line g++ helloworld.cpp doesn't throw up any error. Just to add, I'm using windows 8.
My best guess would be that a.out is not in your directory. Usually, when compiling your program from the command line, add the -o flag and name your executable (like helloworld.exe). Then you'll be sure that an executable of that name is actually being created.
In your case, since you're most likely running Windows, without specifying a -o flag, the default is a.exe and not a.out, so when you used ./a.out that executable didn't exist. In this case, you can run your program by typing a or a.exe. You don't need the leading ./ on Windows.
./a.out
If you are in *NIX world, using linux or any other UNIX related platforms
.(dot) means current directory and a.out is an executable.
ls -l a.out
list its permissions and make sure it has executable permission. If it dont have use following command to give it permission; usually it should have when your generated the a.out file.
chmod 755 a.out
If your file is not in current directory use the absolute path to invoke the executable file
<absolute_path>/a.out
It should work if you have taken care all above criteria.
In the Windows world, "\" is used to separate files and directories:
C:\Windows\System32\Etc
However most other operating systems, and the web, use "/"
file:///c/windows/system32/etc
/etc/motd
In Unix "." refers to the current directory, and Windows/DOS mostly support this.
The Unix-based compilers expect you to specify an output file name for a compilation, and the default is "a.out". But you can override it with "-o"
g++ test.cpp -o test.exe
This creates a file called "test.exe" in the current directory. If you are using MinGW's "bash" command line, you should be able to run the above executable by typing:
./test.exe # note: no spaces!
at a "$" prompt
$ ./test.exe
However, if you are in a directory, say C:\Dev in the DOS command prompt, that won't work. DOS thinks '/' means "start of a parameter":
C:\Dev\> dir /w
outputs "wide" format dir
So, if you're using DOS, you just need to type:
test.exe
or
.\test.exe
e.g.
C:\Dev\> test.exe
C:\Dev\> .\test.exe
C:\Dev\> c:\dev\test.exe
or if you're relying on "a.out"
C:\Dev\> a.out
C:\Dev\> .\a.out
[As Cornstalks explained below, I'm trying to strip a header prefix that's used in an #include. So it appears this question is not a duplicate of How to make g++ search for header files in a specific directory?]
I'm making some changes to a library. I have the library locally, so its not installed in its customary system location.
I have a test source file and its sided-by-side with the library. The test file has a bunch of includes like:
#include <foo/libfoo.h>
And it also has a bunch of customary includes, like:
#include <iostream>
I'm trying to compile the test file using:
$ g++ ecies-test.c++ -I. -o ecies-test.exe ./libcryptopp.a
And (the space between -iquote . does not appear to make a difference):
$ g++ ecies-test.c++ -I. -iquote . -o ecies-test.exe ./libcryptopp.a
The problem I am having is I don't know how to tell g++ that <foo/libfoo.h> means "./libfoo.h". Effectively, I'm trying to strip the prefix used to include the header. I've looked in the manual under 2.3 Search Path, but it does not really discuss this scenario.
I have about 60 extra test files I use for the library. And each has 10 or 20 includes like this. So I can't go through and change #include <foo/libfoo.h> to #include "./libfoo.h" in 500 or 600 places.
I tried #rici's work around by creating the fictitious directory structure, but it broke GDB debugging. GDB cannot find symbols for class members, so I can't set breakpoints to debug the code I am attempting to modify.
How do I tell the compiler to look in PWD for system includes?
Below is a typical error. ECIES_FIPS is in my local copy of the library.
$ g++ -DNDEBUG=1 -g3 -Os -Wall -Wextra -I. -iquote . ecies-test.c++ -o ecies-test.exe ./libcryptopp.a
ecies-test.c++:29:17: error: no member named 'ECIES_FIPS' in namespace
'CryptoPP'
using CryptoPP::ECIES_FIPS;
~~~~~~~~~~^
ecies-test.c++:44:5: error: use of undeclared identifier 'ECIES_FIPS'
ECIES_FIPS<ECP>::Decryptor decryptor(prng, ASN1::secp256r1());
^
ecies-test.c++:44:16: error: 'ECP' does not refer to a value
ECIES_FIPS<ECP>::Decryptor decryptor(prng, ASN1::secp256r1());
^
/usr/local/include/cryptopp/ecp.h:30:20: note: declared here
class CRYPTOPP_DLL ECP : public AbstractGroup<ECPPoint>
...
In case it matters:
$ g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin12.6.0
Thread model: posix
There is no option which tells gcc to ignore directory prefixes in include paths. If your program contains #include <foo/header.h>, there must be some path_prefix in the include list such that path_prefix/foo/header.h resolves to the desired file.
While you cannot configure gcc to ignore the foo, you can certainly modify the filesystem as you please. All you need is that there be somewhere a directory foo which maps onto the directory where the header files are stored. Then you can add the parent of that directory to the search path.
For example:
mkdir /tmp/fake
ln -s /path/to/directory/containing/header /tmp/fake/foo
gcc -I /tmp/fake ... # Ta-daa!
Using the -I option to add the current folder as an include directory, you could create a folder called "foo" in the current directory and put your libfoo.h file inside.
Obviously, this doesn't strip the "foo" prefix in your #include, but it is a workaround.
I have about 60 extra test files I use for the library. And each has 10 or 20 includes like this. So I can't go through and change #include to #include "./libfoo.h" in 500 or 600 places.
If the above criteria is just a matter of convenience, then a tool like sed can be used to do all the work. Something like
$ sed -i 's/\(^\s*#include\s*[<"]\)foo\/\([^>"]*[>"]\s*$\)/\1\2\t\/\/ This line was replaced/' *
will replace all the occurrences of #include <foo/file.h> with #include <file.h> (you might have to adjust it slightly, I'm on a Windows machine at the moment and can't test it). This will work if all the files are in the PWD. If there is a more complex file structure, then it can be used in conjunction with grep and xargs.
NOTE: Make sure that the svn directories are ignored when using.
I've installed at my win8.1 mingw and I would like to compile my program.
When I use command:
g++ -o test test.cpp -lboost_unit_test_framework-mt
I got an error:
no such file od directory:
"#include boost/test/unit_test.hpp" // in "<>" ofc.
when I use my msVS it works fine.
You also must use the -L and the -I option to specify the directories where the boost libraries and headers are located:
g++ -I<path_to_headers> -o test test.cpp -L<path_to_library> -lboost_unit_test_framework-mt
Note for the headers path that should be the path containing the boost directory.
I just recently switched back to Linux from windows and VC, but I never done any special coding using g++ compiler.
Currently my libraries (boost and others) are scattered all over the hard drive and I need to learn how to setup my compiler and linker so that all the compiler settings..
(includes, libs, flags) etc.. will be held in one single file or place, so that it becomes easy to manage, because I don't want to type these things every time I launch the compiler on command line.
Also note that I'm using a vim as my code editor and do not want to use IDE.
What is the best way to achieve that goal?
You need to use some of Building tools. It's allow you type small command (in vim you need just type :make) which launch build process with predetermined parameters (includes, libs, etc).
For C++ in Linux the most common tools are:
- make;
- automake;
- CMake.
If you use Qt also qmake is available.
I've had experience with all of them and my suggestion is use plain make for small projects and CMake for others and don't use autotools while you don't have to do it.
Note: All hight-level tools just help generate appropriate files (Makefile) for plain make (CMake generate Makefile based on CMakeLists.txt, automake based on Makefile.am, qmake based on *.pro).
because I don't want to type these things every time I launch the
compiler on command line.
I don't like to type either. All I want to do for small builds is issue:
(1) a short alias (2) the name of the file to compile, and (3) an output file.
Then I want my tool to take care of all common options, and if necessary, include the paths to any extra -I include directories, -L library directories and form the command line for me.
I have a short script that can handle the drudgery. Separating your projects into separate directories and including a 'bldflags' file with specific options allows the scripts to load any project specific options you may require. It is flexible enough to take any additional options specified on the command line. Alias the script in your .bashrc, and all that is required for quick builds is:
g+ filename.cpp outname
Now this is a very basic script and is not intented to replace proper build tools for your projects, but for quick compilations, it, or something like it, will sure cut down on the typing required. Here is the short script:
#!/bin/bash
## validate input
test -n "$1" && test -n "$2"|| { echo "insufficient input. usage: ${0//*\//} source.cpp out [options]"; exit 1; }
## set standard build flags and test if exists/source ./bldflags
stdclfags="-Wall" # add any standard flags you use.
test -r ./bldflags && bldflags="`<./bldflags`"
## show build command and call g++
echo -e "building $1 with:\n g++ $stdclfags -o $2 $1 $bldflags ${#:3}"
g++ $stdclfags -o "$2" "$1" $bldflags ${#:3}
exit 0
Make the script executable and include a simple alias in your .bashrc giving it any name you like:
alias g+='/home/david/scr/utl/bgc++.sh'
Examples of basic use: (basic without additional flags or a ./bldflags file)
$ g+ input.cpp output
building input.cpp with:
g++ -Wall -o output input.cpp
With a few extra options added on the command line:
$ g+ input.cpp output -Wunused -fno-default-inline
building input.cpp with:
g++ -Wall -o output input.cpp -Wunused -fno-default-inline
Including project specific options in ./bldflags (e.g: -I/home/david/inc -L/home/david/lib -Wl,-rpath=/home/david/lib
g+ input.cpp output -Wunused -fno-default-inline
building input.cpp with:
g++ -Wall -o output input.cpp -I/home/david/inc -L/home/david/lib -Wl,-rpath=/home/david/lib -Wunused -fno-default-inline
So to address the I don't want to type these things every time I launch the
compiler on command line, this is a very quick and easy way I've found to cut the typing down to a minimum for quick/repetitive builds where a full Makefile isn't needed.