Any caveats or gotchas to aliasing cc to refer to Clang within my default shell - zsh (presumably by editing my .zshrc file) while leaving cc aliased to gcc in another shell (bash)?
I find Clang much easier to use mainly because it's warnings and error messages are much more readable and understandable than those of gcc. I will be enrolled in a Unix programming course next semester (purely in C) and am expected to have cleared any gcc -Wall warnings before submission of an assignment.
What I am trying to do is do most of my developing using Clang within my default shell (zsh) using a makefile that refers to the compiler as just cc. Once satisfied I would run it once, as a test, via bash (invoking gcc as the compiler) before submitting. The submitted makefile with cc as the compiler would then invoke gcc for the instructor, making it transparent to them. I am supposed to submit makefiles with each assignment.
I know this just seems like lazyness since I can re-edit the makefile each time, but I am trying to leave less room for error.
Just run
make CC=clang
or
make CC=gcc
or perhaps
make CC='gcc -flto -Wall'
(reminder: -flto should be passed at compile and at link time).
I won't comment on whether this is fine or not, but there is an easier way. Just use a variable in your Makefile to whatever you want the default to be:
CC=gcc
Then you can override this when you invoke make:
make CC=clang
Related
I want to be able to pass arguments to GCC from my C source code, something like this...
// pass the "-ggdb" argument to GCC (I know this won't work!)
#define GCC_DEBUG_ARG -ggdb
int main(void) {
return 0;
}
With this code I'd like to simply run gcc myfile.c which would really run gcc myfile.c -ggdb (as the "-ggdb" argument has been picked up from the C source code).
I'm not interested in using make with the CFLAGS environment variable, I just want to know if its possible to embed GCC options within C source code
What you want to do is not possible in general.
However, recent GCC (e.g. GCC 8 in end of 2018) accepts many options and some of them could be passed by function attributes or by function specific pragmas (However, they don't accept -g but do accept -O2).
Also, you can use -g in every compilation (with GCC, it is mixable with optimization flags such as -O2; so runtime performance won't suffer. Of course the -g will increase compile time and size of produced object file). Notice that (on Linux) the DWARF debug information is visible in the generated assembler file (e.g. try to compile your foo.c with gcc -Wall -g -O -S -fverbose-asm foo.c, look into the generated foo.s, and repeat by removing the -g)
I'd like to simply run gcc myfile.c
That is a very bad habit. You should run gcc -Wall -Wextra -g myfile.c -o myprog to get all warnings (you really want them) and debug info in your executable myprog. Read How to debug small programs before continuing coding your program.
I'm not interested in using make with the CFLAGS environment variable
But you really should. Using make or some other build automation tool (e.g. ninja, omake, rake, etc, etc....) is, in practice, the conventional and usual way of using GCC.
Alternatively, on Linux, write a tiny shell script doing the compilation (this is particularly worthwhile if your program is a single source file; for anything bigger, you really should use some build automation tool). At last, if you use emacs as your source code editor, you could add a few lines of comments (like at end of my manydl.c example) specifying Emacs file variables to tune the compilation (done from emacs)
If these conventions surprise you, read about the Unix philosophy then study -for inspiration- the source code of some existing free software (e.g. on github, gitlab, or in your favorite Linux distribution).
At last, GCC itself is a free software project (but a huge one of more than five millions lines of mostly C++ source code). So you can improve it the way you desire (if you follow its GPLv3+ license), after having studying somehow its source code. That would take you several months (or years) of work (because GCC is very complex to understand).
See also this answer to a related question.
You might also (but I recommend not to, because it is very confusing) play tricks with your PATH variable and have some directory there -e.g. $HOME/bin/, ahead of /usr/bin/ which contains /usr/bin/gcc, with your shell script named gcc; but don't do that, you'll be confused. Instead write some "generic" mygcc shell script which would run /usr/bin/gcc and add appropriate flags to it (I believe it is not worth the effort).
Hello i am new to ubuntu. I want to run a c program in ubuntu.On the terminal i typed "make ex1.c" (my file name is ex1) and the after pressing enter button , terminal is telling me that
"no rule to make target 'ex1.c'. stop " .
How can i proceed?
Try this
$ gcc -Wall ex1.c -o ex1
$ ./ex1
-Wall makes all the warnings explicit. It is considered to be a good practice to always enable -Wall option. -o ex1 specifies the output executable to be ex1.
GCC is the default C compiler on Ubuntu. An elegant introduction to gcc can be read in here.
make needs no rules to make a simple C file, all it needs is the basename, without the .c extension:
make ex1
./ex1
I advise you to start using the gcc command though. You will have more control on how stuff is compiled and along the way, you'll learn how building an application works. make will start making sense if you have a larger project with many (inter dependent) files.
More (a lot!) information here: http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/, or by typing man gcc in the terminal.
Best is to use GCC or you are getting error because you are attaching ".c".So don't put extension in make command.Try without putting extension like following:
make ex1
./ex1
i have written a c program for doubly-linked-list in linux. the program is named as program2.c.
i have compiled it using "cc program2.c -o out2".
it compiled and also executed fine.
even also tried writing a makefile.my makefiel includes
all:doublelinkedlist
doublelinkedlist:program2.c
gcc -Wall -Werror -O2 -o $# $<
clean :
\rm -fr doublelinkedlist
when i did make it gives me the errors.
can any one please help me writing a makefile.
When using a makefile, you also started using the -Wall -Werror flags. This is a very good thing.
Now the compiler looks for more suspicious things in your program, and refuses to compile if it finds anything. This can be a great help in catching bugs.
However, these warnings mean your program doesn't compile, and you'll need to fix them, by changing the code so that the compiler will be sure all is OK (as far as the compiler can check - of course the code can still contain bugs).
Common issues are mixing different types and not paying attention to the const keyword. But for help with specific warnings, you'll need to show the warnings and the code. Or better - search for each of them in StackOverflow, and I'm sure you'll find good answers.
I'm trying to debug an issue where the wrong version of a function gets called causing a segfault. The code that I'm compiling is machine generated and includes a function called 'times' that does a complex multiply of it's two arguments. This code is compiled to a .o before being linked into a higher level object file.
When run this code segfaults and gdb indicates that it's in glibc's version of 'times' which doesn't even take the same number of arguments. The are no instances of '#include anywhere in this code.
Changing the name of times to times1 resolves the problem. This isn't a long term solution though due to the machine generated nature of the code and manually editing the name of this function all the time is unappealing.
The whole mess compiles cleaning with -Wall so I'm not sure where to look. Any ideas on how to resolve this?
Compile chain:
gcc -Wall -I. -g --shared -o dpd.o -fPIC *.c (mahine generated code here)
gcc -g --std=c99 -c -fpic getData.c -I/usr/local/include -L/usr/local/lib -lmatio -I/usr/local/include/iverilog -I$(MATLAB)
gcc -g -shared -o getData.vpi getData.o $(MATLAB)/dpd.o -lvpi -lmatio -L/usr/local/lib
C only uses the name of a function as an identifier, so any two (exported) functions with the same name will conflict. The normal approch is to prefix all exported names in a library with a unique prefix. The other alternative is to use C++ as "a better C" and simply build your C code using a C++ compiler, making use of C++ name mangling.
So the real answer to this one is to throw -fno-builtin-times to gcc. That avoids the problem neatly with no fuss.
This of course assumes that you can't changes the name of times to something that doesn't conflict with a glibc provided function.
Not even quite sure what my question is. The short of it is, for a class I'm supposed to add some functionality to this c file, and it came with a handy makefile.
CFLAGS=-DUNIX -lreadline -lcurses -ansi -pedantic-errors
DEBUG=-g
#DEBUG=
all: shell
shell: shell.c parse.c parse.h
gcc $(CFLAGS) $(DEBUG) shell.c parse.c -o shell
clean:
rm -f shell *~
I have to add features to shell.c. I'm very new to C (usually use c++ or c#) so I'm testing out little things in a separate little tests.c file. Things like, see what exactly certain system calls return, how to printf them right, etc. Anyway, tests.c seems to be conforming to different c compiler standards or I'm compiling it wrong. If I accidentally use // to comment something out or declare a variable somewhere other than at the start in shell.c, the compiler yells at me. It doesn't care in tests.c.
I compile tests.c with "gcc tests.c -o tests"
If I compile the shell using "gcc shell.c parse.c -o shell" it compiles fine, but running it simply gives me a segmentation fault. I would love to ask my TA about this, but every time I as him something he answers a completely different question...
Any thoughts on what's going on here? Perhaps a point in the right direction at least?
The problem is that your makefile includes -ansi -pedantic-errors flags for the compiler. This forces it to use a very old version of C. Perhaps this Makefile was provided by your instructor and he wants like that? It is not uncommon.
To use these new features (// comments, automatic variables anywhere in a block) just drop these two flags. If you have the freedom, I recommend also using -std=c99 -Wall.
To get GCC to accept C99 conventions, tell it to do so:
gcc -std=c99 ...
gcc -std=gnu99 ...
So, add -std=gnu99 to your CFLAGS value, and remove -ansi which is equivalent to -std=c89. If you must code to C89 standards, do not use // comments.
We can't tell what causes the core dump - but it could be that you're trying to modify a string literal somewhere, or any of a large number of other problems.
The -ansi -pedantic-errors prevents the impurities like // and variable definitions in the middle of the function. Remove that and you should be able to sin away.
As for the segmentation fault, your best bet is to run your program through gdb to see where it crashes.
Why are you compiling by calling gcc directly instead of using the makefile? The makefile adds a number of additional command-line gcc options which are most likely important. Do you see the same behavior if you compile using make all?
Since you are new to C, I would recommend adding -Wall to the CFLAGS line. This will enable all compiler warnings, which may alert you to a subtle error that you might have otherwise missed.