I am trying to compile a C library and I am getting a loy of warning while doing it. Though the compiled library is working properly, I am still a bit apprehensive about the warnings. I googled all the warnings, but the relevant search results are hard to come by.
The warnings are:
main(){printf("osx%d", (int) (sizeof(void *)*8));}
^~~~
1 warning generated.
clang: warning: argument unused during compilation: '-s'
This warning is in the shell script that I used to compile the libraries. Could someone tell me what the -'s' flag is and how I can remove this warning?
Next warning:
warning: unknown warning option '-Wno-long-double'; did you mean '-Wno-long-long'? [-Wunknown-warning-option]
and the next one,
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: fortify.o has no symbols
clang: warning: argument unused during compilation: '-s'
Anyway to silence these warning?
Look at the manual of gcc for details of what each option should do.
AFAICT, clang not accepting those flags does not lead to any failure of the built executable.
Excerpt:
-s: Remove all symbol table and relocation information from the executable. (linker)
-Wno-long-double: Looks like someone wants to disable use of long double. Cannot find it for newest GCC. Chances are the code does not contain such anyway.
Related
I have enabled -Werror for C pre processing command to treat warnings as errors.
Basically i wanted to only treat redefined warnings as errors. And all other warnings should not be treated as errors.
In file included from /home/test/version24/test.spec:35:0,
/test/release/base_version.spec:93:0: warning: "CD_MK_FILE" redefined
#define CD_MK_FILE 4
In file included from /home/test/version23/mss_litter.spec:19:0,
from
/test/release/base_version23.spec:0: note: this is the location of the previous definition
#define CD_MK_FILE 3
Is there any flag in to treat only redefined warnings as errors.
Thank you!
How do we enable or disable specific compiler warnings or errors?
For gcc/g++ and clang compilers, try:
# To disable -Werror just for warning -Wwhatever
-Wno-error=whatever
# To **enable** errors just for this one -Wwhatever warning
-Werror=whatever
For the clang compiler, you'd use -Wno-error=macro-redefined, to disable that error for the -Wmacro-redefined warning only, and you'd use -Werror=macro-redefined to enable an error only for that warning.
See here: https://clang.llvm.org/docs/DiagnosticsReference.html#wmacro-redefined. Thanks for the comment under the question, #user3386109!
See the list of all possible warnings and errors here:
For the gcc compiler: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
For the clang compiler (which is gcc-compatible, by design): https://clang.llvm.org/docs/DiagnosticsReference.html
For example, from the gcc link above:
-Werror=
Make the specified warning into an error. The specifier for a warning is appended; for example -Werror=switch turns the warnings controlled by -Wswitch into errors. This switch takes a negative form, to be used to negate -Werror for specific warnings; for example -Wno-error=switch makes -Wswitch warnings not be errors, even when -Werror is in effect.
The warning message for each controllable warning includes the option that controls the warning. That option can then be used with -Werror= and -Wno-error= as described above. (Printing of the option in the warning message can be disabled using the -fno-diagnostics-show-option flag.)
Note that specifying -Werror=foo automatically implies -Wfoo. However, -Wno-error=foo does not imply anything.
Other References:
The comment by #HolyBlackCat
[my Q&A] How can I disable a C/C++ -Werror build error in Bazel? (AKA: how to turn OFF specific warnings already turned on by -Wall -Werror)
Related:
In case you ever need to control just a few lines of code, this is incredibly useful too: How to disable GCC warnings for a few lines of code
I'm a longtime python hobbyist porting a script over to c. I believe there is something wrong in the environment preventing the code from compiling. Research elsewhere leads me to believe it has something to do with posix header files? Maybe something with macros? I'm insufficiently experienced in c to figure it out.
The relevant snippet is here:
pthread_t id;
thread_create(&id, NULL, refreshqb,NULL);
void *status;
pthread_start(id, (void**)&status);
The error I receive is this.
t.c:91:4: warning: implicit declaration of function 'thread_create' is invalid in C99
[-Wimplicit-function-declaration]
thread_create(&id, NULL, refreshqb,NULL);
^
t.c:93:4: warning: implicit declaration of function 'pthread_start' is invalid in C99
[-Wimplicit-function-declaration]
pthread_start(id, (void**)&status);
^
2 warnings generated.
Undefined symbols for architecture x86_64:
"_pthread_start", referenced from:
_main in t-0d3a02.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Support for pthreads must be explicitly enabled when compiling your code. It looks like you're using clang, so just add the -pthread flag when you compile using clang.
Please try using pthread_create, along with including correct posix library header or "#include <pthread.h>".
I have a question, but I'm not sure if it's about C, clang or OSX.
When I compile a simple GLUT program like so:
clang test.c -framework OpenGL -framework GLUT
And I intentionally insert a function call that doesn't exist, like so:
thisFunctionIsNotDefinedAnywhere();
I get an error, as expected. But here's the rub -- I don't get the error until link time!
Undefined symbols for architecture x86_64:
"thisFunctionIsNotDefinedAnywhere" referenced from:
_main in test-e099d2.o
ld: symbol(s) not found for architecture x86_64
Why is this? Is this because pre-C99 there were implicit declarations? I've been programming for a long time and have never run into this before. Is it because I've been spoiled on GCC and MSVC which (I seem to remember) cause a compiler error in this situation? Or does it have to do with how framework linking works in OSX, which I am new to?
I appreciate any clarification!
As expected, this gives a warning with a recent version of clang. I tried it with the version that comes with Xcode 6.1, and got this compiler output:
$ clang test.c
test.c:2:5: warning: implicit declaration of function 'thisFunctionIsNotDefinedAnywhere' is invalid in
C99 [-Wimplicit-function-declaration]
thisFunctionIsNotDefinedAnywhere();
^
1 warning generated.
Undefined symbols for architecture x86_64:
"_thisFunctionIsNotDefinedAnywhere", referenced from:
_main in test-376416.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Since using undeclared functions is legal in C, the compiler message can't be an error. But it does show a clear warning, without specifically enabling warnings with command line options.
Because of implicit function declaration, if you enable warnings then you would be warned that thisFunctionIsNotDefinedAnywhere(); is implicitly declared, returning int by default.
If you add a function prototype, then the warning will be gone, but then at the link stage, the compiler wont find the function definition, and issue the error.
I've recently learned how to program simple character drivers and while playing around with the code I noticed that I get a lot of the following GCC warnings thrown for my C99 code:
warning: ISO C90 forbids mixed declarations and code
I assume this is because the main Linux kernel Makefile is set to compile using a non-C99 standard. I searched around I found this answer here on stackoverflow: How to use make and compile as C99?
So I naturally tried the following in my Makefile:
ccflags-y := -std=gnu99
Unfortunately this didn't silence the GCC warnings. I checked the verbose output of make and verified that GCC is indeed executed with the -std=gnu99 tacked on at the end; so I'm a bit confused.
How do I properly compile a Linux kernel module using the -std=gnu99 option?
EDIT:
I noticed the GCC output shows this option: -Wdeclaration-after-statement. Is this why I am getting the warnings even with the -std=gnu99 option?
It turns out that -std=gnu99 does in fact work; I began seeing errors regarding C99 features after removing the compiler flag. So that meant something else was causing the warnings to print out besides the -std= option.
After parsing through the verbose output via make V=1, I discovered the -Wdeclaration-after-statement option as part of the GCC execution. This was the cause of the ISO C90 mixed declaration warnings I saw.
To disable the ISO C90 warnings, pass this to GCC: -Wno-declaration-after-statement.
For example:
ccflags-y := -std=gnu99 -Wno-declaration-after-statement
You can also specify the flag in your Makefile, if you have one:
FLAGS=-std=gnu99
I compiled gcc 4.5.2 on a 64bit Redhat enterprise 3 machine (2.4.21-20.ELsmp, glibc 2.3.2). It compiles ok but with a lot of warning message like
/tmp/ccbGRF5F.s: Assembler messages:
/tmp/ccbGRF5F.s:29: Warning: rest of line ignored; first ignored character is `d'
/tmp/ccbGRF5F.s:33: Warning: rest of line ignored; first ignored character is `d'
/tmp/ccbGRF5F.s:169: Warning: rest of line ignored; first ignored character is `i'
Then I try to compile code with the compiler, still it spits these asm warnings, and I'm not using any asm in my C code. How can I get rid of it? Fix or suppress warning are all fine.
It seems your binutils is too old to handle gcc-4.5's output - and in another project it might outright end in a compile failure. Given RHEL3, that would not surprise me at all.
I'm assuming you're using the command line to compile? adding a "-w" flag to the compile command will suppress all warnings. For example, to compile hello.c without warnings:
gcc hello.c -w -o hello
Will produce the output file "hello", without spitting out any errors.