I am trying to compile some C code on a beagleboard xm. I try to compile, but I get the error: undefined reference to 'isfinite' which is in the math.h library. This code compiles perfectly in all my other computers, and I do include -lm in my makefile.
I suspect that it may be my compiler, maybe it is an over version? On the beagleboard it's version 4.3.3, but on my computer it's 4.7.3, but I don't know how to get a later version. I thought opkg would automatically get the latest available.
Any ideas why this may be happening?
The function infinite() is part of C99. Your compiler is by default using an older version of the C language. You need to compile with the the flag -std=c99 to enable this macro.
`gnu89' GNU dialect of ISO C90 (including some C99 features). This is
the default for C code.
http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/C-Dialect-Options.html
isfinite is part of the C++11 standard and gcc 4.3.3 is to old to know that. Try
int finite(double x); or int finitef(float x);.
Related
I am trying to compile a C source code to a machine code using an ubunto terminal
My tutor instruction was to use the following command:
running clang myprogramm.c -std=c11
Why shall I use the keyword -std=c11 and what is the difference to using just
clang myprogramm.c
Using std= options is required by your tutor (I'm divinig her motives, I'm particularly good at this!) because she wants to make sure you stay away from all those nifty Clang features that turn the accepted language from C to A LANGUAGE SUPERFICIALLY LOOKING LIKE C BUT ACTUALLY A DIFFERENT LANGUAGE NOT SUPPORTED BY OTHER C COMPILERS.
That is more than just additional library functions. It include syntax changes that break the grammar of Standard C, as defined by ISO. A grasshopper should not use these while learning. Using -std=c11 makes sure Clang either warns about or even rejects, with an error, such constructs.
When to specify the standard? Whenever you use the compiler. It is never a good idea to let the compiler just use whatever it wants.
If someone tries to use a compiler that is too old, then they will get a warning or error, and they will understand why the compile fails.
If a code contributor (maybe even yourself!) tries to add code using features that are too new, their code will be rejected. That's very important if you intend to keep compatibility with an older standard.
By explicitly stating the standard, using new features or extensions are a choice and don't happen by accident.
I'm following a tutorial on learning C. I'm currently using a Mac with clang 11.0.3. It is in C99 by default (I'm getting the error: warning: implicit declaration of function 'of' is invalid in C99
[-Wimplicit-function-declaration].)
I'm using xcode 11.5.
How do I update/change the default of clang to C11 or higher?
You can look up the documentation with man clang on your system or online on the Clang website (https://clang.org → “Getting started” → “User's Manual” link on the left).
clang supports the -std option, which changes what language mode clang uses. The supported modes for C are c89, gnu89, c99, gnu99, c11, gnu11, c17, gnu17, c2x, gnu2x, and various aliases for those modes. If no -std option is specified, clang defaults to gnu17 mode.
Note that since you're seeing C99 as the language version, your IDE is likely passing a -std option already. I don't know where to control compiler options in Xcode but Setting C compile flags in xcode might help.
The Clang documentation is not always complete or clear. Many features of Clang mimic GCC, and GCC often has better documentation. The section on C dialect options in the GCC manual has more information about -std and its values. You need to be careful because Clang doesn't always work exactly like GCC, but the GCC documentation is often helpful as long as you remember that it may not always apply to Clang.
None of this will help you anyway because switching from C99 to C11 wouldn't fix this particular error. Implicit function declarations are a deprecated feature in C89 which was made invalid in C99, and of is not a new keyword in C11, so either your code is bad-style C89 or more likely there's a typo and of should not be a function name.
I am using codeblock 13.12 and it uses mingw (GCC 4.7 & 4.8 Series)
It supports call by reference (func1(int &a)) eventhough I am selecting C project and not CPP project. If I am not mistaken, there is no concept of call by reference in C and everything is call by value even if it is making use of pointers.
My question is how to use C only features? Any settings for this? I saw that in toolchain it is using mingw32-gcc.exe for c compilations.
How to know which compiler version (Like C11, C99 etc) it is really using?
Name your files with an extension of .c. And definitely not .cc or .cpp
Compile with gcc as the command line, not g++
And if in doubt, use the -std= command line parameter to force the flavor of C you want (e.g. -std=C90, -std=C99, or even -std=C11 ). There's also -ansi.
Also, a cheap and dirty way to validate if your code is getting compiled as C and not C++ is to add this block of code within your source code. If it's C++, then the compiler will generate an error.
#ifdef __cplusplus
int compile_time_assert[-1];
#endif
Is there any way to compile C code with c89 standard NOT c99 in Xcode (or another way with terminal)?
I've searched in Xcode settings but I didn't find any way to choose compiler or standard.
You should add -pedantic-errors to Other C flags in your project settings, like so:
Of course, don't forget to set the C language dialect to C89 as well.
This will give you the appropriate compile time errors when you try to compile something that is not valid C89.
Optionally, if you want Xcode to compile your code regardless of incompatibilities, but only give you yellow warnings at the problematic lines, use -pedantic instead of -pedantic-errors.
In a nutshell, these flags make the compiler stick to the language standard more strictly, as opposed to the default behavior, which is to attempt compiling the code any way possible.
I hope this helps :)
Source
(even though they mention this in the context of GCC, but the same flags apply for Clang as well)
I am currently writing a C program with threads and I make use of pthread_cleanup_push_defer_np() and pthread_cleanup_pop_restore_np(). Provided that:
I have included pthread.h;
I am compiling with -pthread option;
I am on Ubuntu 14.04 and using gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1);
when compiling I get back a nasty undefined reference error to the above mentioned functions and I can't figure out why. I have tried to take a look into pthread.h and it seems those two functions are commented out, so I am wondering whether I need to enable them in some way or use some other kind of options. I've read the manual pages and google it up but I can't find a solution, so I would appreciate a little help. Here it is a snippet:
void *start_up(void *arg)
{
char *timestamp;
// ... code ...
timestamp = get_current_timestamp("humread");
pthread_cleanup_push_defer_np(free, timestamp);
// ... some other code
pthread_cleanup_pop_restore_np(1);
// ... more code ...
}
I compile with
gcc -pthread -o server *.c
The manual of pthread_cleanup_push_defer_np and pthread_cleanup_pop_restore_np say these two (non portable) functions are GNU extensions and are enabled
by defining _GNU_SOURCE:
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
pthread_cleanup_push_defer_np(), pthread_cleanup_pop_defer_np():
_GNU_SOURCE
This results in linker error (as opposed to compile time error) because your compiler is pre-C99 (or you are compiling in pre-C99 mode) and assumes these functions return int by default.
The rule functions-return-int if no prototype is present has been removed since C99. Enabling more compiler switches can help you with better diagnostics.