error #1696: Implicit pointer conversion changes byteorder of the pointed-to types from "bigendian int" to "int"
if((processid = forkpty{{int*)&(execData->mFd)
I have multiple files being compiled by a single makefile. One of those files say xyz.cis giving me byte-order error I tried to resolve such errors using this https://software.intel.com/en-us/node/628915
But this one is sticky. No matter what I do it didn't go away.
Attempts Made:
1) Went through https://software.intel.com/en-us/node/628915 but nothing helped.
2)if I take this file say xyz.c out of the makefile and comment it then it gives me undefined reference to lots of functions which are used elsewhere. So this is obviously not a solution.
Need is to ignore this warning so I
Wonder if there is a way to make-Wnoerror for a particular file being compiled inside a Makefile.
There are two possible options,
Create a rule for the specific file in the Makefile, and don't pass -Werror when compiling it.
Use what is described in this answer.
#pragma GCC diagnostic ignored "-W(your specific warning)"
you can re-enable the warning later if you like.
Related
So I am trying to identify some memory corruption issues in a large codebase. To begin with, I first built the codebase as it is with whatever existing makefile configuration was set up already. It worked fine and the binaries were generated. Now I added -g -fsanitize=address -fno-omit-frame-pointer -fno-common in compile flags and -fsanitize=address (also tried with -lasan if that makes any difference) in link flags to compile the codebase with ASan. But now I am getting multiple declaration errors at link time. I am clueless at this point. What could be the reason for this? If there were multiple definitions, then shouldn't the same error pop up when building without ASan flags too? I couldn't even find anything related to this in the ASan docs.
I cannot share the exact error trace, but it pretty much looks like this:
path/to/file/hdr.h:132: multiple definition of `myDataTable_type'
path/to/file/hdr.h:132: first defined here
path/to/obj/file/obj.o: multiple definition of `__odr_asan.myDataTable_type'
gcc --version
gcc (GCC) 8.4.1 20200928 (Red Hat 8.4.1-1)
Most likely you have something like
XXX myDataTable_type;
in one of the headers. When this header is included into multiple source files you'll get multiple definitions error under -fno-common.
To resolve this you could either remove -fno-common from CFLAGS but then Asan will not be able to detect buffer overflows in some static arrays. Better yet, just get rid of multiple definitions by changing declaration in header to
extern XXX myDataTable_type;
and adding
XXX myDataTable_type;
to one of the source files (to guarantee single definition).
I took Linux kernel version 4.9.30, added a new directory /fsac whose files include headers from other directory (/include/fsac) and that is almost all I changed. Trying to compile I get a lot of errors in /kernel/sched/core.c that look like this:
kernel/sched/core.c:2326:20: error: invalid storage class for function ‘set_schedstats’
kernel/sched/core.c:2342:19: error: invalid storage class for function ‘setup_schedstats’
(...)
Searching on-line I saw that the recommendation was to simply remove the 'static' from the functions. Doing that effectively avoided that errors, but instead I started getting a lot of warnings from objtool like "frame pointer state mismatch" for each of the functions whose static was removed.
I discovered these warnings can be avoided by changing in the configuration file CONFIG_STACK_VALIDATION=n. That worked but even though there is no warning, compilation fails (Error 2).
Hence, I am wondering:
1 - Is the removal of "static" from the offended functions the proper solution?
2 - If so, how do I deal with the objtool warnings? Can those warnings alone constitute a compilation error, or there must be something else?
3 - Do you think I should degrade GCC?
This is the source code of the project: https://github.com/Zildj1an/FSAC_Kernel
This is the compilation log w/o removing the statics: https://github.com/Zildj1an/FSAC_Kernel/blob/master/build_err
I will happily provide any other information you might need.
Cheers.
Problem found, I had a function inside a function... Probably was moved copying something else.
I want to get rid of all implicit-function-declaration warnings in my codebase. But there is a problem because some functions are
programmed into the microcontroller ROM at the factory and during linking a linker script provides only the function address. These functions are called by code in the SDK.
During compilation gcc of course emits the warning implicit-function-declaration. How can I get rid of this warning?
To be clear I understand why the warning is there and what does it mean. But in this particular case the developers of SDK guarantee that the code will work with implicit rules (i.e. implicit function takes only ints and returns an int). So this warning is a false positive.
This is gnu-C-99 only, no c++.
Ideas:
Guess the argument types, write a prototype in a header and include that?
Tell gcc to treat such functions as false positive with some gcc attribute?
You can either create a prototype function in a header, or suppress the warnings with the following:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wimplicit-function-declaration"
/* line where GCC complains about implicit function declaration */
#pragma GCC diagnostic pop
Write a small program that generates a header file romfunctions.h from the linker script, with a line like this
int rom_function();
for each symbol defined by the ROM. Run this program from your Makefiles. Change all of the files that use these functions to include romfunctions.h. This way, if the linker script changes, you don't have to update the header file by hand.
Because most of my programming expertise was acquired by self-study, I intentionally have become somewhat anal about resolving non-fatal warnings, specifically to avoid picking up bad coding habits. But, this has revealed to me that such bad coding habits are quite common, even from formally trained programmers. In particular, for someone like me who is also anal about NOT using MS Windows, my self-study of so-called platform-independent code such as OpenGL and Vulkan has revealed a WORLD of bad coding habits, particularly as I examine code written assuming the student was using Visual Studio and a Windows C/C++ compiler.
Recently, I encountered NUMEROUS non-fatal warnings as I designed an Ubuntu Qt Console implementation of an online example of how to use SPIR-V shaders with OpenGL. I finally threw in the towel and added the following lines to my qmake .PRO file to get rid of the non-fatal-warnings (after, first, studying each one and convincing myself it could be safely ignored) :
QMAKE_CFLAGS += -Wno-implicit-function-declaration
-Wno-address-of-packed-member
[Completely written due to commends]
You are compiling the vendor SDK with your own code. This is not typically what you want to do.
What you do is you build their SDK files with gcc -c -Wno-implicit-function-declaration and and your own files with gcc -c or possibly gcc -o output all-your-c-files all-their-o-files.
C does not require that declarations be prototypes, so you can get rid of the problem (which should be a hard error, not a warning, since implicit declarations are not valid C) by using a non-prototype declaration, which requires only knowing the return type. For example:
int foo();
Since "implicit declarations" were historically treated as returning int, you can simply use int for all of them.
If you are using C program, use
#include <stdio.h>
I am compiling a function and getting warning:
**/tmp/ccPFK7nG.o: warning gets is dangerous and should not be used.**
Now I know why the warning is coming, the part that I am not aware is the location from where the warning is coming keeps changing.
Every time I compile the code the location is /tmp/some_file.o
Is it like gcc makes the temporary object file in /tmp directory and when the executable is made it removes it from there?
Every time I compile the code the location is /tmp/some_file.o Is it like gcc makes the temporary object file in /tmp directory and when the executable is made it removes it from there?
What you see is a side effect of the -flto option in gcc, that enables link time optimization. The compiled source for this second pass is indeed a temporary, containing precompiled data from object files.
To see the real culprit, you may need to remove this option and recompile, although the warning should appear with the correct file location in the first pass.
Suggest to remove the usage of gets(). Since ISO C11 removes the specification of gets() from the C language.
http://linux.die.net/man/3/gets
Read BUGS and Conforming to section.
If compiling and linking at the same time, such as
gcc a.c b.c c.c -o wholeprogram
each mentioned C module gets compiled into a temporary object file, then all object files are linked together to get the final executable.
The names of these temporary obejct files are created dynamically and on the fly and, thus, change on every invocation.
Under what situation is it possible for GCC to not throw an "undefined reference" link error message when trying to call made-up functions?
For example, a situation in which this C code is compiled and linked by GCC:
void function()
{
made_up_function_name();
return;
}
...even though made_up_function_name is not present anywhere in the code (not headers, source files, declarations, nor any third party library).
Can that kind of code be accepted and compiled by GCC under certain conditions, without touching the actual code? If so, which?
Thanks.
EDIT: no previous declarations or mentions to made_up_function_name are present anywhere else. Meaning that a grep -R of the whole filesystem will only show that exact single line of code.
Yes, it is possible to avoid reporting undefined references - using --unresolved-symbols linker option.
g++ mm.cpp -Wl,--unresolved-symbols=ignore-in-object-files
From man ld
--unresolved-symbols=method
Determine how to handle unresolved symbols. There are four
possible values for method:
ignore-all
Do not report any unresolved symbols.
report-all
Report all unresolved symbols. This is the default.
ignore-in-object-files
Report unresolved symbols that are contained in shared
libraries, but ignore them if they come from regular object
files.
ignore-in-shared-libs
Report unresolved symbols that come from regular object
files, but ignore them if they come from shared libraries. This
can be useful when creating a dynamic binary and it is known
that all the shared libraries that it should be referencing
are included on the linker's command line.
The behaviour for shared libraries on their own can also be
controlled by the --[no-]allow-shlib-undefined option.
Normally the linker will generate an error message for each
reported unresolved symbol but the option --warn-unresolved-symbols can
change this to a warning.
TL;DR It can not complain, but you don't want that. Your code will crash if you force the linker to ignore the problem. It'd be counterproductive.
Your code relies on the ancient C (pre-C99) allowing functions to be implicitly declared at their point of use. Your code is semantically equivalent to the following code:
void function()
{
int made_up_function_name(...); // The implicit declaration
made_up_function_name(); // Call the function
return;
}
The linker rightfully complains that the object file that contains the compiled function() refers to a symbol that wasn't found anywhere else. You have to fix it by providing the implementation for made_up_function_name() or by removing the nonsensical call. That's all there's to it. No linker-fiddling involved.
If you declare the prototype of the function before using it , it shold compile. Anyway the error while linking will remain.
void made_up_function_name();
void function()
{
made_up_function_name();
return;
}
When you build with the linker flag -r or --relocatable it will also not produce any "undefined reference" link error messages.
This is because -r will link different objects in a new object file to be linked at a later stage.
And then there is this nastiness with the -D flag passed to GCC.
$cat undefined.c
void function()
{
made_up_function_name();
return;
}
int main(){
}
$gcc undefined.c -Dmade_up_function_name=atexit
$
Just imagine looking for the definition of made_up_function_name- it appears nowhere yet "does things" in the code.
I can't think of a nice reason to do this exact thing in code.
The -D flag is a powerful tool for changing code at compile time.
If function() is never called, it might not be included in the executable, and the function called from it is not searched for either.
The "standard" algorithm according to which POSIX linkers operate leaves open the possibility that the code will compile and link without any errors. See here for details: https://stackoverflow.com/a/11894098/187690
In order to exploit that possibility the object file that contains your function (let's call it f.o) should be placed into a library. That library should be mentioned in the command line of the compiler (and/or linker), but by that moment no other object file (mentioned earlier in the command line) should have made any calls to function or any other function present in f.o. Under such circumstances linker will see no reason to retrieve f.o from the library. Linker will completely ignore f.o, completely ignore function and, therefore, remain completely oblivious of the call to made_up_function_name. The code will compile even though made_up_function_name is not defined anywhere.