I am trying to use the Constant M_LN2 from the math.h library but always seem to get a compiler error. The code is:
#include <stdio.h>
#include <math.h>
int main(){
double x = M_LN2;
printf("%e",x);
return 0;
}
compiling with gcc on ubuntu
gcc -std=c99 lntester.c -o lntester -lm
getting output:
error: 'M_LN2' undeclared
any help in understanding why this is happening would be greatly appreciated.
As stated below the if def were not getting defined and using gcc and c99 were causing the issue. Below is the compile code that solved the issue and allowed me to use c99.
gcc -std=c99 -D_GNU_SOURCE lntested.c -o lntester -lm
any help in understanding why this is happening would be greatly
appreciated.
You can open /usr/include/math.h and try to found definition of M_LN2. For me it is defined and wrapped by condition macros:
#if defined __USE_BSD || defined __USE_XOPEN
...
# define M_LN2 0.69314718055994530942 /* log_e 2 */
...
#endif
When you compile your code with option -std=c99 neither __USE_BSD no __USE_XOPEN defined, so all variables which wrapped by if define not defined too.
You can compile your code without -std=c99 option or with -std=gnu99 option instead.
Related
I have toy code that looks like this
#include <stdlib.h>
#include <unistd.h>
int main()
{
readlink("/proc/self/exe", "/my/path", 128);
return EXIT_SUCCESS;
}
When I compile with
icc main.c -o helloworld
everything is fine but when I e.g. try
icc -std=c99 main.c -o helloworld
or
icc -std=c11 main.c -o helloworld
I get the error message
main.c(6): warning #266: function "readlink" declared implicitly
What is it about c11 (or c99) standards that induces this error?
The definition is wrapped in
#if defined __USE_XOPEN_EXTENDED || defined __USE_XOPEN2K
From the man page for readlink you need to set the proper source definition first.
The current POSIX definition can be set with gcc -std=c11 -D_POSIX_C_SOURCE=200809L
If you don't set everything correctly you get to hunt undefined behavior because sizeof(int) and sizeof(void*) aren't the same anymore. Implicit declarations really did need to go for 64 bit to become.
-std=gnu11 flips everything on. If you don't have to care if you accidentally use a gcc extension or not, just set it in your makefile and forget about it.
I did a minimal c file (main.c)
#if !defined(MBEDTLS_CONFIG_FILE)
#error "not defined"
#else
#include MBEDTLS_CONFIG_FILE
#endif
int main(void)
{
while(1);
}
now calling arm-none-eabi-gcc main.c gives error: #error "no defined" and this is OK.
But calling arm-none-eabi-gcc main.c -DMBEDTLS_CONFIG_FILE="test.h" gives error: #include expects "FILENAME" or <FILENAME> so it is defined but not to the value I expect.
What is the correct syntax ? (context: this is working from the IDE but I want to move to cmake)
It's the shell that removes the quotes from the string you pass. You need to escape the quotes to keep them in the macro:
arm-none-eabi-gcc main.c -DMBEDTLS_CONFIG_FILE=\"test.h\"
I'm trying to measure the amount of time an operation is taking, as accurately as possible. My research led me to believe that clock_gettime() and friends is what I want.
However, I can't for the life of me get it to work. Consider this seemingly trivial example:
#include <time.h>
#include <unistd.h>
int main(void)
{
struct timespec t;
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &t);
return 0;
}
If I run that through the preprocessor, everything looks like it's just fine:
$ cpp time.c | tail -n10
# 1163 "/usr/include/unistd.h" 3 4
# 3 "time.c" 2
int main(void)
{
struct timespec t;
clock_gettime(2, &t);
return 0;
}
However, if I try to compile the preprocessed code, it won't:
$ cpp time.c > time-prep.c
$ cc -o time -Wall -std=c11 -lrt time-prep.c
/tmp/user/1000/cc00SdhB.o: In function `main':
time-prep.c:(.text+0x15): undefined reference to `clock_gettime'
collect2: error: ld returned 1 exit status
$
If I try to compile the original, it doesn't go any better:
$ cc -o time -Wall -std=c11 -lrt time.c
time.c: In function ‘main’:
time.c:6:18: error: storage size of ‘t’ isn’t known
time.c:7:2: warning: implicit declaration of function ‘clock_gettime’ [-Wimplicit-function-declaration]
time.c:7:16: error: ‘CLOCK_PROCESS_CPUTIME_ID’ undeclared (first use in this function)
time.c:7:16: note: each undeclared identifier is reported only once for each function it appears in
time.c:6:18: warning: unused variable ‘t’ [-Wunused-variable]
$
The man page for clock_gettime says that I need to
Link with -lrt (only for glibc versions before 2.17).
but as you can see, I'm already doing that. Adding or removing -lrt to cc doesn't seem to make any difference whatsoever in my case.
I have looked at /usr/include/time.h but don't see anything obvious that I am missing.
What (presumably trivial) incantation is missing for me to be able to use clock_gettime() in my code?
The Linux documentation for clock_gettime() specifies a feature-test requirement:
_POSIX_C_SOURCE >= 199309L
You could consider fulfilling that directly, perhaps via a #define directive at the very beginning of your code, since the code in fact does depend on it.
If you do not provide such a #define, then gcc may nevertheless do it for you, depending on the options you specify to it. By default, it will do. Likewise with -std=gnu99 or -std=gnu11. But you attempted to compile with -std=c11, which asks for strict(ish) compliance with C11. C11 does not define the needed POSIX feature-test macro.
You can define _GNU_SOURCE above any #include. There is an example:
$cat ./main.c
// Need for clock_gettime()
// Have to be at the begining of the file
#define _GNU_SOURCE
#include <time.h>
#include <unistd.h>
int main(void)
{
...
}
I have this code:
#include <string.h>
#include <stdio.h>
char numbers[5] = "12345";
int main(){
memrchr(numbers,'2',5);
for(int i=0;i<5;i++){
printf("%d",i);
}
return 0;
}
It uses for loop inital declarations (for(int i) and gnu extensions (memrchr).
I am using the compiler gcc
The problem is that it doesn't seem to let both go through. I can either do
gcc program.c -o program
Which complains about the for loops, or I can do
gcc -std=gnu11 program.c -o program
Which complains about memrchr being undefined. (or rather it complains about the implicit declaration of the function)
How do I do both? Is it possible?
You need to define the _GNU_SOURCE feature-test macro before any library #include. A convenient way to do that is to put it in your command line:
gcc -std=c11 -D_GNU_SOURCE program.c -o program
Or you could put the #define at the very top of every file which needs it. (Putting them in the source file is probably better, but I've gotten into the habit of putting them in my Makefiles. YMMV.)
You can see the needed feature-test macros in the manpage for every C library function. For example, man memrchr includes:
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
memrchr(), rawmemchr(): _GNU_SOURCE
As that says, man feature_test_macros will tell you more.
I'm coding a program that uses ossp-uuid which defines a type called uuid_t. Now, the problem that I have is that this type is already defined in Mac OSX in the file unistd.h.
So, the error I get is:
/opt/local/include/ossp/uuid.h:94: error: conflicting types for 'uuid_t'
/usr/include/unistd.h:133: error: previous declaration of 'uuid_t' was here
I complile my program with:
gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -
DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\"
-DPACKAGE=\"epride\" -DVERSION=\"0.2\" -I. -I/usr/local/BerkeleyDB.4.7/include
-I/opt/local/include -I/opt/local/include/db47 -I/opt/local/include/libxml2
`pkg-config --cflags glib-2.0` -DNUM_REPLICAS=1 -DGEN_SIZE=10 -g -O2 -MT
libepride_a-conflictset.o -MD -MP -MF .deps/libepride_a-conflictset.Tpo
-c -o libepride_a-conflictset.o `test -f 'conflictset.c'
|| echo './'`conflictset.c
Is there a way to tell gcc that he should ignore the type from unistd.h? Because I'm using unistd.h for other things.
In uuid.h there is these lines:
/* workaround conflicts with system headers */
#define uuid_t __vendor_uuid_t
#define uuid_create __vendor_uuid_create
#define uuid_compare __vendor_uuid_compare
#include <sys/types.h>
#include <unistd.h>
#undef uuid_t
#undef uuid_create
#undef uuid_compare
Shouldn't that take care of it?
Thanks in advance!
You should check /opt/local/include/ossp/uuid.h at line 94 and hope that there's a define for uuid_t. Hopefully you'll find something like:
#ifndef UUID_T_DEFINED
#define UUID_T_DEFINED
typedef uuid_t .... whatever
#endif
If the guys who wrote that header did it in this way, then you can modify your code:
#include <unistd.h>
#define UUID_T_DEFINED
#include <ossp/uuid.h>
This way, he second #include won't hit the declaration of uuid_t in ossp/uuid.h.
Something like this?
#define uuid_t unistd_uuid_t
#include <unistd.h>
#undef uuid_t
#include <ossp/uuid.h> /* or whatever header you're including */
It's ugly, but well, it's C...
If you have access to the ossp-uuid library source code, then you can rename the offending identifier to something like ossp_uuid_t with simple text search-and-replace. Recompile and reinstall the library and everything should be fine.
This may be more complicated than what you need, but one option is to wrap ossp-uuid inside a shared library, and create an API that doesn't expose the underlying uuid_t type.