I'm using vim on Mac OS X, and my vimrc contains these keymappings:
function! CPPSET()
set makeprg=if\ \[\ -f\ \"Makefile\"\ \];then\ make\ $*;else\ if\ \[\ -f\ \"makefile\"\ \];then\ make\ $*;else\ g++\ -std=gnu++0x\ -O2\ -g\ -Wall\ -Wextra\ -o\ %<\ %;fi;fi
set cindent
set nowrap
nnoremap <buffer> <F9> :w<cr>:!g++ -O2 % -o %< -std=c++14 -I ./<cr>:!./%<<cr>
nnoremap <buffer> <F8> :w<cr>:!g++ -Wall -Wextra -Wshadow -O2 % -o %< -std=c++11 -I ./<cr>
endfunction
I'm using these keymappings to both compile and run when I press F9. It works fine until today: I notice that the file won't compile and give the following error when I include these headers:
#include <stack>
#include <queue>
I notice that when I remove two these headers from my cpp file, it works fine. Moreover, when I try to compile that file (with these two headers included) with
g++ hello.cpp (instead of using F9 in Vim)
It works just fine. Please take a look! I've tried reinstalling xcode, but it didn't work.
In file included from queue.cpp:16:
./queue:1:1: error: source file is not valid UTF-8
<CF><FA><ED><FE><U+0007><U+0000><U+0000><U+0001><U+0003><U+0000>
<U+0000><80><U+0002><U+0000><U+0000><U+0000><U+0010><U+0000><U+0000>
<U+0000>p<U+0006><U+0000><U+0000><85>...
./queue:1:2: error: source file is not valid UTF-8
<CF><FA><ED><FE><U+0007><U+0000><U+0000><U+0001><U+0003><U+0000>
<U+0000><80><U+0002><U+0000><U+0000><U+0000><U+0010><U+0000><U+0000>
<U+0000>p<U+0006><U+0000><U+0000><85>...
./queue:1:5: error: expected unqualified-id
<CF><FA><ED><FE><U+0007><U+0000><U+0000><U+0001><U+0003><U+0000>
<U+0000><80><U+0002><U+0000><U+0000><U+0000><U+0010><U+0000><U+0000>
<U+0000>p<U+0006><U+0000><U+0000><85>...
^
./queue:1:6: warning: null character ignored [-Wnull-character]
<CF><FA><ED><FE><U+0007><U+0000><U+0000><U+0001><U+0003><U+0000>
<U+0000><80><U+0002><U+0000><U+0000><U+0000><U+0010><U+0000><U+0000>
<U+0000>p<U+0006><U+0000><U+0000><85>...
^
./queue:1:7: warning: null character ignored [-Wnull-character]
<CF><FA><ED><FE><U+0007><U+0000><U+0000><U+0001><U+0003><U+0000>
<U+0000><80><U+0002><U+0000><U+0000><U+0000><U+0010><U+0000><U+0000>
<U+0000>p<U+0006><U+0000><U+0000><85>...
...continue
Edit:
This is what Syntastic identifies: here
When I compile with g++ simply, it works seamlessly: here
Comments out #include , #include and Syntastic is satisfied:here
You have (according to your pictures) a binary file (probably an executable) named queue in your working directory. For some weird reason you need to discover, it gets included with #include <queue> (look into the actual program arguments passed to g++ by your editor or IDE). Remove that file.
(as a rule of thumb, avoid naming your programs with the same name as usual things on your computer; having an executable named queue is bad taste for a C++ developer)
You might want to pass -H to g++ to understand what files are included.
Then take several hours or days to read the documentation on Invoking GCC and learn to use some build automation tool, such as GNU make or ninja. For make, read documentation of make then write your own Makefile (caveat: tab characters are significant). For ninja see this. You need to understand how g++ should be invoked.
At last, read the documentation of your source code editor (or IDE) and configure it for your needs and tastes. You might want it to run some make or ninja command at a single function keypress. How to do that is explained in the documentation. For vim, see this.
The important thing to understand is that IDEs are just source code editors capable of running some external command to build your software. You can configure that command. C++ compilers are -practically speaking- always command line programs (usually GCC or Clang), and you need to learn how to invoke them (you generally should prefer to use a build automation tool to run your compilation commands).
Related
I'm trying to compile a CPP application (an open source project) in the latest cygwin64 environment using g++ 6.4.0 and I get the following error:
error: 'posix_memalign' was not declared in this scope
now posix_memlign can be found in stdlib.h if you compile the most simple CPP "hello world" application there wouldn't be a problem calling posix_memlign.
The make file of the project report the following setup for the compilation
g++ -DHAVE_CONFIG_H -I. -Wall -Wnon-virtual-dtor -I. -I./include -g -O3 -std=c++0x -g -O3 -std=c++0x -MT lib/rectangular_binary_matrix.lo -MD -MP -MF lib/.deps/rectangular_binary_matrix.Tpo -c lib/rectangular_binary_matrix.cc -DDLL_EXPORT -DPIC -o lib/.libs/rectangular_binary_matrix.o
so it doesn't look like it override the default include path. Any ideas?
p.s.
I was able to build the code on Linux (Redhat) without a problem.
posix_memalign is not part of the C Standard Library or the C++ Standard
library and the cygwin GCC compilers do not provide it, although other
compilers may do so, including GCC compilers from other builders.
You might consider using instead the C Standard function aligned_alloc, if you feel comfortable to edit your project source. It is provided in <cstdlib> for C++ compilation in cygwin g++ 6.4.0
Later
I do see the function in C:\cygwin64\usr\include\stdlib.h...
The fact that you can find the function declaration in the header file
does not mean that the compiler can see it after preprocessing. The same
source header may be used by many builders, exposing different
declarations to the compiler depending on the builder's settings of implementor
macros. In this case, the declaration is concealed from your compiler by
the fact that __POSIX_VISIBLE >= 200112 is false. Identifiers beginning __ are reserved for implementors.
See the explanation of this macro
and note the comment:
* The following private macros are used throughout the headers to control
* which symbols should be exposed. They are for internal use only, as
* indicated by the leading double underscore, and must never be used outside
* of these headers.
[SOLUTION FOUND]
Hello (I'm posting this on 2 threads regarding the same problem).
I'm here because I had the "POSIX_VISIBLE >= 200112" and the "posix_memalign was not declared in this scope" issue, which was halting the compilation of a program.
I'm not a programmer and tried various fixes on my own for a couple hours. Then finally Googled & came upon this site. The solutions here did not work for me, but I'll describe what did work:
The "posix_memalign" text was in a "stdlib.h" file that was being included into the code. The first problem was that in my "cygwin" directory, I have 25 instances of "stdlib.h"! Which one of those was being included?! I'm all new to this, but I finally found that
echo | gcc -E -Wp,-v -
might at least give an idea of which directory the files were being "included" from. This narrowed down the number of "stdlib.h" files to 4. Out of 4 such files, only one had the "posix_memalign" text. I tried changing the filename of that stdlib.h to see if it would cause an error--and confirm that it was the stdlib.h in question. However, this didn't effect the program. So I searched for a "stdlib.h" file in the next directory higher. THAT "stdlib.h" file also had the "POSIX" text in it. So when I changed THAT stdlib.h filename, the program DID error out. So that was the stdlib.h to deal with.
I saw that the "POSIX_VISIBLE >= 200112" instruction effected only the ONE line of code with "posix_memalign" in it. (In other words, the "POSIX_VISIBLE" instruction was not being used for the whole file.) I considered "commenting" it out, or deleting it. But then non-programmer me got the ingenious idea to simply change the ">=" to a "<". So I now had "POSIX_VISIBLE < 200112". I saved the file, ran the "configure" and "make" routine again, and boom, all was well. Program compiled properly.
Moral of the story, if you can determine the file (containing the POSIX statement and the posix_memalign) which is being accessed by your code, you may be able to solve your problem by just changing that one POSIX_VISIBLE operator as I did. (And you may want to switch that operator back after your compiling is done, in case that stdlib.h library file needs to be used by other programs in the future.)
Before you asked, yes i did look this up FOR DAYS. Im completely stuck... I'm using MINGW32 (my shortcut says MSYS) to compile my c and cpp code. For about 2 or 3 days now I have been getting strange errors. (below) It was working JUST FINE before. I even ran the same code i've compiled before and it gave the same error. I then go into DevC++ and open then compile an it works just fine.
ERRORS:
namespace: command not found
using: command not found
syntax error:
int main(){
(sometimes it gives me a big unreadable mess)
I'm really stuck... I dont want to have to switch to DevC++... I like to use my own text editor and compile in a command line.
From your errors namespace: command not found and using: command not found says to me that you aren't compiling the code with an appropriate compiler.
For reference in MinGW32 toolchain:
gcc.exe = C
g++.exe = C++
You may find it useful to take a look at what the IDE's actualy do with your compiler.
My current IDE allows me to see all the commands that it runs to build my project:
C:/mingw32/bin/g++.exe -c "C:/MyProgram/main.cpp" -g -O0 -std=c++14 -Wall -o ./Obj/main.cpp.o -I. -IDependencies/Something/include
So lets examine what this does.
My current toolchain is MinGW32 which is located in C:/mingw32/bin/g++.exe
g++ is our c++ compiler so we call g++.exe and we pass the following switch:
-c "C:/MyProgramm/main.cpp"
This tells my compiler to compile the main.cpp from my project directory. then my IDE adds a few additional command line switches. For the purpose of the answer I will only consider -o. This tells us the output file from our code main.cpp into an output file.
The reason we produce such a file is to save us time compiling so that we do not have to compile the same file twice without making changes to it. We perform this step on each of our files creating a collection of .o files.
The new file is then saved in "C:/MyProgramm/Obj/main.cpp.o"
Which means that your command line function will look something like this:
C:/mingw32/bin/g++.exe -c "<my project directory>/<file>.cpp" -o ./Obj/<file>.cpp.o
I would recommend that you read up on documentation for the g++ function and learn from different IDE's as you will soon find that you need to do more advanced things with your compiler.
For example to enable features from c++14 I add -std=c++14
*Edited to reflect feedback.
I have this simple file, called lol.c
#include <iostream>
using namespace std;
int main() {
return(0);
}
From terminal, i type g++ lol.c
This is the output:
In file included from /usr/include/wchar.h:36:0,
from /usr/include/c++/4.9/cwchar:44,
from /usr/include/c++/4.9/bits/postypes.h:40,
from /usr/include/c++/4.9/iosfwd:40,
from /usr/include/c++/4.9/ios:38,
from /usr/include/c++/4.9/ostream:38,
from /usr/include/c++/4.9/iostream:39,
from lol.c:1:
/usr/include/stdio.h:30:22: fatal error: SDL_main.h: File o directory non esistente
#include "SDL_main.h"
^
compilation terminated.
I don't know if the problem is something with SDL, but when i try to run ../configure to install it, i have this:
configure: error: cannot run C compiled programs.
See `config.log' for more details
If is this needed, i can put config.log file too.
There are multiple problems:
you gave a .c extension to a C++ source file; that is wrong, C++ files should have a .cpp (or .cxx, .C, .c++, the last two are a bit frowned upon) extension, or the compiler may try to compile it as C code;
you are invoking gcc instead of g++; this is wrong too, calling gcc on C++ files misses several options required to compile and link correctly (including, but not limited to, linking against the C++ standard library); that was in an older revision of the question, now it says g++;
but most importantly, your build environment is completely broken (some would say "FUBAR"); it is not normal that /usr/include/stdio.h includes stuff from SDL (the fact that it cannot be found is just a minor incident compared to this); you should really purge and reinstall anything related to gcc and to the headers of the C library; look for some libc6-dev package (or similar) to reinstall (be careful not to mess with the C library proper, or your system may be rendered essentially unbootable).
You can't give .c (c extension) to a c++ file.
1 - Change it to .cpp (c++ extension, lol.cpp)
2 - You have to give options to g++ (in your case use -o to create executable file) g++ lol.cpp -o nameofyourprogram
3 - Execute through your terminal ./nameofyourprogram
I was trying to figure out how to link Fortran and C++ code, and one of the tutorials had written 2 programs, one in C++ in a file named testC.cpp, and the other in Fortran in a file named testF.f but I need to input the following compilation instructions:
gfortran -c testF.f
g++ -c testC.cpp
g++ -o test testF.o testC.o -lg2c
Problem is, I'm working in an IDE called Bloodshed Dev-C++ so I have no idea how to do this. I tried going in compiler options and in the general section I appended those instructions in the option "add the following commands when calling the compiler". Doesn't work.
Maybee you need use custom Makefile. Project->project options. Or include *.mak files
First some background - I have three VS2010 C++/OpenCL projects that compile and run fine on Windows 7 64-bit. I've been trying to compile and run each of them on Linux 64-bit (Ubuntu/Debian). The first two are compiling and running on linux and don't really use any external libraries. The third uses only Boost 1.50.0 and isn't compiling using the same method as the first two. So first let me go through what I did to get the first two to work.
I extracted only the source from the myriad of folders.
I ported windows specific code to linux specific code.
I wrote a bash script to generate the g++ command with all sources to compile them.
I ran the compile script to generate an output target file.
The bash script is as follows.
#!/bin/bash
SOURCE=""
for i in `ls *.h *.cpp *.hpp`; do
SOURCE+="${i} "
done
COMMAND="g++ -I/home/junkie/downloads/boost_1_51_0 -o out ${SOURCE} -L/opt/AMDAPP/lib/x86_64/ -I/opt/AMDAPP/include -lOpenCL -fpermissive"
echo -e "\n"
echo -e "${COMMAND}"
echo -e "\n"
$COMMAND
exit $?
And it generates and runs a command similar to following.
g++ -I/home/junkie/downloads/boost_1_51_0 -o out blah.cpp blah.h foo.hpp baz.cpp etc.cpp -L/opt/AMDAPP/lib/x86_64/ -I/opt/AMDAPP/include -lOpenCL -fpermissive
I compile using the following command.
./compile.sh &> log; echo $?; grep -ci error log; wc -l log
Now you may be wondering why I've adopted such unconventional and redundant means of getting a C++ project to compile and run on linux. Well because I'm new to the linux c and c++ toolchain and this was the quickest and simplest route I could figure out to get the job done and it did get the first two projects up and running. However, the third uses boost and this method isn't working and I need your help in figuring out what all these strange errors are.
The errors I'm getting are not actually from the project code but instead from Boost and AMD's opencl libraries code which is strange because the other projects were using opencl too and those worked fine.
Some examples of boost errors are below.
foo.hpp:2331:1: error: unterminated argument list invoking macro "BOOST_PP_CAT_I"
In file included from main.cpp:4:
foo2.hpp:1610:1: error: unterminated argument list invoking macro "BOOST_PP_CAT_I"
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: variable or field ‘BOOST_PP_CAT_I’ declared void /home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp: At global scope:
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: variable or field ‘BOOST_PP_CAT_I’ declared void
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected ‘;’ at end of input
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected ‘;’ at end of input
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected ‘}’ at end of input
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected unqualified-id at end of input
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected ‘}’ at end of input
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected ‘}’ at end of input
foo.hpp:2331:1: error: unterminated argument list invoking macro "BOOST_PP_CAT_I"
Some examples of opencl errors are below.
In file included from /opt/AMDAPP/include/CL/cl_platform.h:35,
from /opt/AMDAPP/include/CL/cl.h:30,
from bar.h:7,
from fooGPU.hpp:6,
from main.cpp:4:
/usr/include/stdint.h:49: error: expected ‘;’ before ‘typedef’
In file included from /opt/AMDAPP/include/CL/cl.h:30,
from bar.h:7,
from fooGPU.hpp:6,
from main.cpp:4:
/opt/AMDAPP/include/CL/cl_platform.h:41: error: expected unqualified-id before string constant
main.cpp:136: error: expected ‘}’ at end of input
main.cpp:136: error: expected unqualified-id at end of input
main.cpp:136: error: expected ‘}’ at end of input
main.cpp:136: error: expected ‘}’ at end of input
The boost includes I'm Using are as follows.
#include <boost/preprocessor/punctuation/paren.hpp>
#include <boost/preprocessor/punctuation/comma.hpp>
#include <boost/static_assert.hpp>
#include <boost/type_traits/is_same.hpp>
#include <boost/type_traits/is_base_of.hpp>
#include <boost/mpl/not.hpp>
#include <boost/mpl/int.hpp>
#include <boost/mpl/logical.hpp>
#include <boost/mpl/eval_if.hpp>
#include <boost/mpl/identity.hpp>
#include <boost/shared_ptr.hpp>
#include <boost/array.hpp>
So, finally, my questions are as follows.
1) What is the root cause of these errors in light of the building method I'm using and how do I resolve this problem? Does order of files or library inclusion matter? I'm using a local source download of boost as part of my g++ command as instructed by boost documentation rather than prebuilt binaries as I'm not using anything that requires prebuilt binaries.
2) I realise that my way of building things is pretty primitive. I'm learning make and I've seen some recommendations to use cmake and kdevelop which I need to look into. The primary problem with using make is that these projects weren't written with make in mind so I'm not aware of the dependency graph between source files to create the makefile (if I'm thinking correctly; I'm still fairly new to it). If you have any recommendations of how to do things better please do enlighten me.
Thanks.
I finally managed to overcome this problem and here I provide a brief account of how. To be clear I don't know what the root cause of the original problem was. In other words - I don't know why the problem occurred. All I'm saying is that my workaround allowed me to resolve the issue and move onto other problems (compile time errors).
Essentially, to reiterate, the problem was that for whatever reason a project using boost wasn't compiling on Linux because all instances of the use of the BOOST_PP_CAT() function produced the following error.
error: unterminated argument list invoking macro "BOOST_PP_CAT_I"
For whatever reason the compiler wasn't able to correctly process the use of this function but was able to process the use of other boost functions such as BOOST_PP_LPAREN(), BOOST_PP_RPAREN() and BOOST_PP_COMMA. The problem looked almost certainly related to the preprocessing stage where the combined use of the aforementioned boost functions was resulting in an unterminated argument list.
To elaborate on the nature of the relevant code (which was not written by me thankfully) the prior developers had essentially used boost preprocessor functions to create a DSL that they could then re-use multiple times to generate a list of functions. It would have seemed a lot easier to me to simply write the functions directly but anyway that's another concern.
My work around was to change the relevant section of code so that it didn't use any BOOST_PP_CAT() functions but ultimately defined the exact same functions as before. I did this by substituting the use of BOOST_PP_CAT() with the code that was being generated by it. This overcame all instances of the error quoted above but left me with hundreds of other compile time errors in my efforts to migrate this project from windows to linux.
Although this was a very specific and unusual question with an equally specific and unusual answer I wanted to feed this back to dispel the mystery behind this problem. As to why this particular function was failing to preprocess/compile on linux but passing on Windows I don't know but would very much like to know. I can only assume it is a fundamental difference in the way VC++ performs preprocessing as opposed to g++ and clang or more specifically perhaps a difference in the order of resolution of nested functions in preprocessor directives. Who knows. Anyway, thanks for your help guys.
The unterminated argument list invoking macro error suggests a lacking closing parenthesis. Use your editor's parenthesis matcher to check it. Be sure that your source files are in Unix format, not in DOS format (e.g. with \n à la Unix, not with\r\n à la MSDOS, at each end-of-line). Use dos2unix if needed.
Otherwise, don't forget that you can run g++ -Wall -C -E -H -I/home/junkie/downloads/boost_1_51_0 yoursourcecode.cc to get the preprocessed form of yoursourcecode.cc, and, by redirecting that command, you can inspect that preprocessed form with the editor of your choice (like emacs).
As I commented, learn to use Gnu make (and if in trouble debugging your Makefile, which you should edit with a good editor like emacs, use remake -x to debug it).
And the -I/home/junkie/downloads/boost_1_51_0 looks very suspicious: even if Boost is often a header only library, it has, as far as I remember, an installation procedure on Unix (and Linux distributions often package Boost libs). You should install your Boost libraries as documented (and after having configured them), and likewise for OpenCL.