I'm trying to build GCC for use with an AVR microcontroller and avr-ada, and I've hit a roadblock caused by my regular compiler being too picky about the version I needed for the AVR. I get the following warning, which in turn causes GCC or Make to report an error:
gcc -c -g -O2 -gnatpg -gnata -nostdinc -I- -I. -Iada
-I../../gcc/ada ../../gcc/ada/exp_ch5.adb -o ada/exp_ch5.o
exp_ch5.adb:177:16: warning: function "Has_Address_Clause" is not referenced
make[2]: *** [ada/exp_ch5.o] Error 1
make[1]: *** [all-gcc] Error 2
make: *** [all] Error 2
Is there a way to instruct GCC or Make to not fail on warnings?
Try make -k instead of just make. That will 'continue' rather than stop.
As an alternative to diving into the build system, try setting -Wno-error in CFLAGS, which you should be able to do through the environment (or at configure time, if using the GNU build system).
The trigger here is the -gnatpg (actually, the -gnatg): this is the "GNAT implementation mode (used for compiling GNAT units)". -gnatp means "suppress all checks".
I'm not sure of the full effect of -gnatg, though it certainly causes warnings to be treated as errors -- like -Werror -- at any rate while building the compiler itself; I think I remember seeing non-fatal warnings while building the RTS.
One possibility would be to compile just exp_ch5.adb by hand without -gnatg; the command you list was issued at gcc/, so
$ cd gcc
$ gcc -c -g -O2 -gnatp -gnata -nostdinc -I- -I. -Iada -I../../gcc/ada \
../../gcc/ada/exp_ch5.adb -o ada/exp_ch5.o
Then back up one level, and 'make' again.
This is a cross-compiler, so you won't (I hope!) need to repeat this for all three stages of a full build.
It seems the -Werror flag is set in the Makefile. Maybe you can look for the CFLAGS options in the Makefile and remove the -Werror flag. The Werror flag will make all warnings into errors.
In general, it is not a good idea to ignore warnings from your compiler. However, if this is a portion of a larger make process there is likely a -Werror flag inserted earlier in the sequence. Start by looking for that.
After looking around, there seems to be a wealth of flags to control warnings while compiling Ada code. For instance, -gnatwF will Suppress warnings on unreferenced formals according to this guide. Possibly the switch you require can be found in the list provided there.
In gcc configure you can add --disable-werror.
Though it's advisable to seek out a proper patch first.
Put "pragma warnings(off, "...")" into the offending parts of your code.
See http://www.adacore.com/2007/11/19/ada-gem-18/.
Related
I have some warning when compiling a piece of code using pthread_cleanup_push/pop with -O2 CFLAGS. Just by removing the O2 cflags in the Makefile make it compile without issue.
Is it forbidden to use gcc optimization with these pthread macros ? I was not able to find anything in man or documentation. By the way, is there any alternative to clean stuff at the end of a thread ? Also it is working perfectly with gcc arm. But not on x86 gcc.
Warning :
x/x.c:1292:2: warning: variable ‘__cancel_routine’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Wclobbered]
pthread_cleanup_push(x_cleanup, &fd);
My current CFLAGS option :
-W -Wall -Wformat -Wformat-security -Wextra -Wno-unused-result,
-Wextra -Wno-long-long -Wno-variadic-macros -Wno-missing-field-initializers
-std=gnu99 -O2
This issue has been reported several times now in GCC tracker (see here). I believe that this warns about real issue in pthread.h (see my comment). __cancel_routine is not marked as volatile so it's value is indeed undefined after return via longjmp which may cause arbitrary consequences.
The only solution is to remove the Werror until a fix ?
I'd rather go with -Wno-clobbered, to keep other warnings enabled.
Roll back on a previous version of gcc on x86 ?
You'll have to rollback to pre-2014 times which is quite a change... I think that if the code works for you, just disable -Wclobbered (with a descriptive comment).
But I did want to be sure that its was not a bigger issue which can cause unexpected behavior of my code or bugs.
Glibc code looks really suspicious. I'd wait for comments from GCC devs and if there is none, report this to Glibc developers.
I'm trying to build a very simple C program for inclusion into a .deb package. The bulk of the project is in Python. When this program is included into a .deb package, lintian gives me the hardening-no-fortify-functions warning.
On further reading, it appears that Debian expects you to include certain flags while building C programs, and that these flags can be retrieved using dpkg-buildflags --get CFLAGS.
My initial build flags looked like this:
gcc -Wall -pedantic -o somefile somefile.c
Now, I'm building with
CFLAGS=`dpkg-buildflags --get CFLAGS`
gcc $CFLAGS -o somefile somefile.c
However, I continue to get the hardening-no-fortify-functions warning. What am I doing wrong here? Is this now a false positive? Can I just add an override and forget about it?
There are several possibilities of which the third seems most likely, but I've mentioned 1 and 2 in case they are causing you problems too:
dpkg-buildflags --get CFLAGS is returning the wrong thing. On my system it returns:
-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security
If you just execute it from the command line, what do you get?
Your value of CFLAGS is not being passed to gcc. I assume you are using a Makefile here; are those two statements actually adjacent? Do you not want CFLAGS = (with a space) if so? Or are you setting CFLAGS at the command line in which case you should know the debian build tool stuff strips the environment of most things that don't start DEB_, so you will need to set CFLAGS inside whatever builds the package.
The CFLAGS aren't sufficient to eliminate the hardening error. Let's have a look at the lintian error: http://lintian.debian.org/tags/hardening-no-fortify-functions.html and note it says 'Certainty: wild guess'. That does not inspire confidence that it is correct. However, I suspect the actual problem is this: you are not bringing in LDFLAGS. Try:
$ dpkg-buildflags --get LDFLAGS
-Wl,-Bsymbolic-functions -Wl,-z,relro
You'll need those on your linker line.
This approach would seem to work (i.e. at least compile):
gcc `dpkg-buildflags --get CFLAGS` `dpkg-buildflags --get LDFLAGS` main.c -o main
I am failed to compile builtin example hwserver.c using ZeroMQ APIs. I have tried every possible way.
gcc -lzmq hwserver.c -o hwserver
It prompts me with:
hwclient.c:(.text+0x22): undefined reference to `zmq_ctx_new'
hwclient.c:(.text+0x3a): undefined reference to `zmq_socket'
hwclient.c:(.text+0x52): undefined reference to `zmq_connect'
hwclient.c:(.text+0x94): undefined reference to `zmq_send'
hwclient.c:(.text+0xb8): undefined reference to `zmq_recv'
hwclient.c:(.text+0xe4): undefined reference to `zmq_close'
hwclient.c:(.text+0xf0): undefined reference to `zmq_ctx_destroy'
collect2: error: ld returned 1 exit status
I'm using zeromq-3.2.2 on ubuntu-12.10
Any help really appreciated.
Thanks,
-Sam
Order of arguments to gcc does matter a lot.
Try
gcc -Wall -g hwserver.c -lzmq -o hwserver
You need first the warning and optimizations or debugging flags (e.g. -Wall for all warnings, -g for debugging information), then the optional preprocessor flags (like -D or -I but you have none of them), then the source files, and at last the libraries -lzmq (order is relevant: from high level libraries to low level ones) and the output option -o hwserver (which could be elsewhere).
Read the gcc documentation, notably the chapter about invoking GCC.
Don't forget the -Wall : you really want to get all warnings, and you should improve your code till no warnings are given. You could even want -Wextra to get more extra warnings.
Don't forget the debugging information flag -g: you will need to use the gdb debugger to debug your program.
Later, use -O or -O2 to optimize the binary program (the compiler will then produce more efficient, but less debuggable, machine code). Care about that only when your program is debugged.
As soon as you want to develop real-sized C programs (i.e. your project made of several source files and some header file[s]), you'll need a builder infrastructure, like GNU make (a very common builder; you could try omake instead).
See also this answer to a related question.
try again
gcc hwserver.c -o hwserver -lzmq
Your order of the parameters is incorrect.
I am trying to gprof my program. I want a line-by-line profiling.
However, I can't seem to get the syntax right. I am using "make" and not "gcc" so please help only with suggestions that fit make. I wouldbe very grateful if you can give me the full "make" syntax.
Based on this website:
http://sourceware.org/binutils/docs/gprof/Output-Options.html[^]
http://sourceware.org/binutils/docs/gprof/Line_002dby_002dline.html[^]
Here is what I am inputting:
make USE_LOCAL_HEADERS=0 LDFLAGS='-L.' BASE_CFLAGS=-m32 CFLAGS='-fopenmp -pg -l -g'
The output is:
/usr/bin/ld: cannot find -l-g
collect2: ld returned 1 exit status
make[2]: *** [build/release-linux-ppc64/ioquake3.ppc64] Error 1
make[2]: Leaving directory `/r/home7/yasir/minoru/cfe2/yasirTemp/ioquake3dev/svfb_201110271440/ioquake3dev_clean'
make[1]: *** [targets] Error 2
make[1]: Leaving directory `/r/home7/yasir/minoru/cfe2/yasirTemp/ioquake3dev/svfb_201110271440/ioquake3dev_clean'
make: *** [release] Error 2
I need option "-l", "-g" and "-pg".
-pg enables profiling, -g includes symbol names which help interpreting the profile generated.
The -pg option needs to be passed to compiler and linker.
The -l command does not make sense in the way you are using it, as it needs a library name as parameter, so as long as you do not provide one, leave the -l away.
Also during development I'd recommend the -Wall option to enable all warnings during compilation.
So you might try this make command:
make USE_LOCAL_HEADERS=0 LDFLAGS='-L. -pg' BASE_CFLAGS=-m32 CFLAGS='-fopenmp -pg -g -Wall'
You can pass most of those as environment variables, make "should" do the right thing and use them for the compiler:
$ USE_LOCAL_HEADERS=0 \
LDFLAGS='-L.' \
BASE_CFLAGS=-m32 \
CFLAGS='-fopenmp -pg -g' \
make
That will USE_LOCAL_HEADERS, LDFLAGS, BASE_CFLAGS and CFLAGS as environment variables which make and gcc can see. You may have to edit your Makefile to combine them in the correct ways for what you want.
make is simply a "to determine automatically which pieces of a large program need to be recompiled, and issue the commands to recompile them" (man make). It looks like make cannot make sense of your arguments; it doesn't actually get to run any commands before it encounters an error.
I'm sorry I can't help you any further, but your problem is within your make file or similar. You should read up on what a make file is, and how to gprof your program and understand the difference between make and gcc, and reevaluate what you are trying to do. Make may not be useuful to you.
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.