I am using Cygwin for my compiler while coding in Codeblocks IDE. Here is what I did in Cygwin 64:
$ gcc -std=c99
gcc: fatal error: no input files
compilation terminated.
However, it's not working. What is the proper way to do this?
To compile a c program in its simplest form to a certain standard, you can use the following command:
gcc -std=c99 -W -Wall main.c -o main
Related
What I want to do it's to create an alias for the sentence below:
g++ -g -pedantic -Wall -o executablefilenamehere pathoffiletocompilehere
Because I have to compile single files frequently.
To do it, I'm trying creating a txt file with the output file name and the
path of the file to compile. So I have a txt, called tocompile.txt, file that contains:
test /home/me/test.cpp
then, I assign to a var that I call tocompile the content of tocompile.txt:
tocompile=`cat tocompile.txt`
This is working, because if i do echo $tocompile I'm getting: test /home/me/test.cpp
So, then, I'm trying to create the alias doing:
alias gxxcomp='g++ -g -pedantic -Wall -o $tocompile'
It doesn't work, when I do:
gxxcomp
I get:
g++: error: missing filename after ‘-o’
g++: fatal error: no input files
compilation terminated.
What's the right way to do that?
Does
alias gxxcomp='g++ -g -pedantic -Wall -o `cat tocompile.txt`'
work for you? At least in my bash version that works.
But as already mentioned in my comment, I would recommend a simple Makefile for this job. Create a file called Makefile with the contents
test: test.cpp
g++ -g -pedantic -Wall -o $# $<
and run make. Check out a tutorial, e.g., this one.
I'm trying to compile my project and I use the lib ncurse. And I've got some errors when compiler links files.
Here is my flags line in Makefile:
-W -Wall -Werror -Wextra -lncurses
I've included ncurses.h
Some layouts :
prompt$> dpkg -S curses.h
libslang2-dev:amd64: /usr/include/slcurses.h
libncurses5-dev: /usr/include/ncurses.h
libncurses5-dev: /usr/include/curses.h
prompt$> dpkg -L libncurses5-dev | grep .so
/usr/lib/x86_64-linux-gnu/libncurses.so
/usr/lib/x86_64-linux-gnu/libcurses.so
/usr/lib/x86_64-linux-gnu/libmenu.so
/usr/lib/x86_64-linux-gnu/libform.so
/usr/lib/x86_64-linux-gnu/libpanel.s
And here are my erros :
gcc -W -Wall -Werror -Wextra -I./Includes/. -lncurses -o Sources/NCurses/ncurses_init.o -c Sources/NCurses/ncurses_init.c
./Sources/NCurses/ncurses_init.o: In function `ncruses_destroy':
ncurses_init.c:(.text+0x5): undefined reference to `endwin'
./Sources/NCurses/ncurses_init.o: In function `ncurses_write_line':
ncurses_init.c:(.text+0xc5): undefined reference to `mvwprintw'
./Sources/NCurses/ncurses_init.o: In function `ncurses_init':
ncurses_init.c:(.text+0xee): undefined reference to `initscr'
collect2: error: ld returned 1 exit status
Thanks a lot
You need to change your makefile so that the -lncurses directive comes after your object code on the gcc command line, i.e. it needs to generate the command:
gcc -W -Wall -Werror -Wextra -I./Includes/. -o Sources/NCurses/ncurses_init.o -c Sources/NCurses/ncurses_init.c -lncurses
This is because object files and libraries are linked in order in a single pass.
In C++ , I fixed it just by linking the ncurses library .
Here is the command :
g++ main.cpp -lncurses
I got flags to correct order by using LDLIBS variable:
ifndef PKG_CONFIG
PKG_CONFIG=pkg-config
endif
CFLAGS+=-std=c99 -pedantic -Wall
LDLIBS=$(shell $(PKG_CONFIG) --libs ncurses)
man gcc | grep -A10 "\-l library"
-l library
Search the library named library when linking. (The second alternative with the library as a separate argument is only for POSIX
compliance and is not recommended.)
It makes a difference where in the command you write this option; the linker searches and processes libraries and object files
in the order they are specified. Thus, foo.o -lz bar.o searches
library z after file foo.o but
before bar.o. If bar.o refers to functions in z, those functions may not be loaded.
When I run across on web, I found this question how to use verilog PLI communicate with c by ncverilog compiler
And I followed the last answer but It does not work.
One of the error is hello_vpi.c : "vpi_user.h No such file or directory"
hello_vpi.c 12 : error 's_vpi_systf_data'undeclared(first use in this function)
....
What should I for solving?
update
#Greg :: My simulator is Incisive15.10.002 and Linux6.0.
I have got a problems which is when I ran like this gcc hello_vpi.c -fPIC -shared -o hello_vpi.so -I /cadence/Incisive/Incisive15.10.002/tools.lnx86/include then I have got some message as following.
hello_vpi.c : Infunction 'register_hello' :
hello_vpi.c :16: warning: assignment from incompatible pointer type.
And I have got some error messages as following when I run this command
ncverilog test.v +access+r -v hello_vpi.so
...
*W.LIBNOU : Library "hello_vpi.so given but not used.
...
$hello;
unrecognized system task or function
...
libvpi.so cannot open shaed object file: No such file directory or file is not valid ELFCLASS64 library
...
*E, MSSYSTF : user defined system task or function( $hello) registered during elaboration and used with in the simulation has not been registered during simulation.
I have no idea what am I suppose to do?
Remove the spaces after -I
gcc hello_vpi.c -fPIC -shared -o hello_vpi.so -I/cadence/Incisive/Incisive15.10.002/tools.lnx86/include
You can also try: (note: I'm guessing the path the the gcc that comes with Incisive)
/cadence/Incisive/Incisive15.10.002/tools.lnx86/bin/gcc hello_vpi.c -fPIC -shared -o hello_vpi.so
If ncverilog test.v +access+r -v hello_vpi.so doesn't work, try:
ncverilog test.v +access+r -loadvpi ./hello_vpi.so:register_hello
A am using below command to compile my c++ code and which is using OpenCV libraries and my command is just like
opencv main.cpp -o binary_name
where opencv is an alias command like
alias opencv="g++ `pkg-config --cflags opencv` `pkg-config --libs opencv`"
but if I forget the "-o binary_name" the command delete my source file. Why this happening....?
What modification should I made on the above alias command to compile my source file like
opencv main.cpp binary_name
Thanks in advance.......
The order of arguments to gcc is important, source or object files should be given before libraries, and libraries should be invoked with higher level libraries before the lower level libraries they are using.
So you should compile with
g++ -Wall -g $(pkg-config --cflags opencv) main.cpp \
$(pkg-config --libs opencv) -o binaryprog
But you really should use a Makefile, or at least have a shellscript.
Don't forget the -Wall option to get all warnings. Improve your code till no warnings are given by the compiler. Use the -g option to get debugging information, to be able to use gdb ./binaryprog to debug your program.
Once your program is debugged, replace -g by -O3 (or perhaps by -O2 -g) to ask GCC to optimize the generated code.
You can use a function instead of an alias, and use arguments:
function opencv() { g++ `pkg-config --cflags opencv` `pkg-config --libs opencv` "$1" -o "$2"; }
I compiled a library which use the g++ instead gcc. First I thought the source code was written in C++ but I found out later that there was not any C++ code in the *.cc files.
To confirm this, I replaced the g++ in the original makefile with gcc. And I still got the correct program.
Anyone can explain this? It was not the first time I met such a situation.
It depends on what exactly you changed in the makefile. gcc / g++ is really just a front-end driver program which invokes the actual compiler and / or linker based on the options you give it.
If you invoke the compiler as gcc:
it will compile as C or C++ based on the file extension (.c, or .cc / .cpp);
it will link as C, i.e. it will not pull in C++ libraries unless you specifically add additional arguments to do so.
If you invoke the compiler as g++:
it will compile as C++ regardless of whether or not the file extension is .c or .cc / .cpp;
it will link as C++, i.e. automatically pull in the standard C++ libraries.
(see the relevant bit of the GCC documentation).
Here's a simple program which detects whether or not it has been compiled as C or C++.
(It makes use of the fact that a character constant has the size of an int in C, or a char in C++. sizeof(char) is 1 by definition; sizeof(int) will generally be larger - unless you're using an obscure platform with >= 16-bit bytes, which you're probably not.)
I've called it test.c and copied it as test.cc as well:
$ cat test.c
#include <stdio.h>
int main(void)
{
printf("I was compiled as %s!\n", sizeof('a') == 1 ? "C++" : "C");
return 0;
}
$ cp test.c test.cc
$
Compiling and linking test.c with gcc, and test.cc with g++, works as expected:
$ gcc -o test test.c
$ ./test
I was compiled as C!
$ g++ -o test test.cc
$ ./test
I was compiled as C++!
$
Compiling and linking test.cc with gcc doesn't work: it compiles the code as C++ because the file ends in .cc, but fails at the link stage:
$ gcc -o test test.cc
/tmp/ccyb1he5.o:(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
collect2: ld returned 1 exit status
$
which we can prove by separately compiling with gcc, and linking with g++ (to pull in the right libraries):
$ gcc -c test.cc
$ g++ -o test test.o
$ ./test
I was compiled as C++!
$
...gcc has compiled the code as C++ rather than C, because it had a .cc file extension.
Whereas g++ does not compile .c files as plain C:
$ g++ -o test test.c
$ ./test
I was compiled as C++!
$
It could be that the .cc code happens to be C, but was intended to be linked into a C++ library. The internals are different.
g++ automatically links the C++ runtime library — gcc doesn't. Obvoiusly, when it doesn't matter — then it doesn't matter, but, as already pointed out by spraff, it could be intended for future use.
I don't know why they chose to use g++ instead of gcc, but I believe it shouldn't matter, as any valid C program is also valid C++.