I am trying to compile timersub() function in linux but i always get:
test.c: In function ‘main’:
test.c:27:2: warning: implicit declaration of function ‘timersub’ [-Wimplicit-function-declaration]
timersub(&now, &then, &diff);
^
/tmp/ccLzfLsl.o: In function `main':
test.c:(.text+0x55): undefined reference to `timersub'
collect2: error: ld returned 1 exit status
this is just a simple code of the function with all the library that i use..
#define _XOPEN_SOURCE
#define _POSIX_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <sys/time.h>
#include "openflow.h"
#include "cbench.h"
#include "fakeswitch.h"
#include <unistd.h>
int main()
{
struct timeval now, then, diff;
gettimeofday(&then,NULL);
sleep(1);
gettimeofday(&now, NULL);
timersub(&now, &then, &diff);
return 0;
}
i am compiling it with:
gcc --std=c99 -Wall -DTRACE -o test test.c
See the manual. It's not in POSIX but in BSD function. So you need _BSD_SOURCE.
Define it at the top:
#define _BSD_SOURCE
or alternatively compile with:
gcc --std=c99 -Wall -DTRACE -D_BSD_SOURCE -o test test.c
Since Glibc 2.20, the macro _BSD_SOURCE has been deprecated and has been superseded by _DEFAULT_SOURCE. From feature test macros:
_DEFAULT_SOURCE (since glibc 2.19)
This macro can be defined to
ensure that the "default" definitions are provided even when the
defaults would otherwise be disabled, as happens when individual
macros are explicitly defined, or the compiler is invoked in one of
its "standard" modes (e.g., cc -std=c99). Defining _DEFAULT_SOURCE
without defining other individual macros or invoking the compiler in
one of its "stan‐ dard" modes has no effect.
The "default" definitions comprise those required by POSIX.1-2008 and
ISO C99, as well as various definitions originally derived from BSD
and System V. On glibc 2.19 and earlier, these defaults were
approximately equivalent to explicitly defining the following:
cc -D_BSD_SOURCE -D_SVID_SOURCE -D_POSIX_C_SOURCE=200809
But if you are using an older Gblic, you'd still need to use _BSD_SOURCE.
Basically i just deleted #define _XOPEN_SOURCE and #define _POSIX_SOURCE and compiled it only with gcc -Wall -DTRACE and it worked
Related
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'm using clock_gettime in a program. I've tried including as well as but neither works. I have also added -lrt to my compiler arguments but still I get the same errors.
This is on
CentOS Linux release 7.2.1511 (Core)
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4)
GNU ld version 2.23.52.0.1-55.el7 20130226
ldd (GNU libc) 2.17
Compiler output:
gcc -o main packet.c connect.c transport.c accept.c main.c close.c util.c receive.c send.c congestion.c -Wall -g -std=c99 -lrt
util.c: In function ‘millis’:
util.c:42:21: error: storage size of ‘t’ isn’t known
struct timespec t;
^
util.c:43:5: warning: implicit declaration of function ‘clock_gettime’ [-Wimplicit-function-declaration]
clock_gettime(CLOCK_MONOTONIC_RAW, &t);
^
util.c:43:19: error: ‘CLOCK_MONOTONIC_RAW’ undeclared (first use in this function)
clock_gettime(CLOCK_MONOTONIC_RAW, &t);
^
Makefile
CFLAGS = -Wall -g -std=c99
LIBS = -lrt
# Should be equivalent to your list of C files, if you don't build selectively
SRC=$(wildcard *.c)
main: $(SRC)
gcc -o $# $^ $(CFLAGS) $(LIBS)
Top of util.h
#ifndef UTILS_438_H_
#define UTILS_438_H_
#include "const.h"
#include "data.h"
#include "transport.h"
#include <time.h>
Top of util.c
#include "util.h"
#include <time.h>
#include <stdio.h>
#include <string.h>
Please let me know if I can supply more information to help answer this
Before including the header(<time.h>), do
#define _POSIX_C_SOURCE 199309L
http://man7.org/linux/man-pages/man2/clock_gettime.2.html
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
clock_getres(), clock_gettime(), clock_settime():
_POSIX_C_SOURCE >= 199309L
http://man7.org/linux/man-pages/man7/feature_test_macros.7.html
_POSIX_C_SOURCE
Defining this macro causes header files to expose definitions as
follows:
· The value 1 exposes definitions conforming to POSIX.1-1990 and
ISO C (1990).
· The value 2 or greater additionally exposes definitions for
POSIX.2-1992.
· The value 199309L or greater additionally exposes definitions
for POSIX.1b (real-time extensions).
· The value 199506L or greater additionally exposes definitions
for POSIX.1c (threads).
· (Since glibc 2.3.3) The value 200112L or greater additionally
exposes definitions corresponding to the POSIX.1-2001 base
specification (excluding the XSI extension). This value also
causes C95 (since glibc 2.12) and C99 (since glibc 2.10)
features to be exposed (in other words, the equivalent of
defining _ISOC99_SOURCE).
· (Since glibc 2.10) The value 200809L or greater additionally
exposes definitions corresponding to the POSIX.1-2008 base
specification (excluding the XSI extension).
Simply replace -std=c99 with -std=gnu99.
Thisway you do not have to add _POSIX_C_SOURCE
if you can use the following linker and Compiler flags
CFLAGS = -g -Wall -std=c99 -D_POSIX_SOURCE -D_GNU_SOURCE
LDFLAGS = -lpthread -lrt
you can get the build done in the Linux systems. -lrt linker and -D_POSIX_SOURCE are the important ones
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.
Here is a little C source code using pthread_kill() call:
#include <stdlib.h>
#include <pthread.h>
#include <signal.h>
int main(int argc, char *argv[])
{
pthread_t th = NULL;
pthread_kill(th, 0);
return 0;
}
Gcc compilation produces various results depending on -std argument value (see below). I don't understand these different behaviors.
I didn't get interesting informations into man pages except pthread_kill() is POSIX.1-2008 compliant.
Environment: Linux 3.2 64bits. GCC 4.7.2.
With -std=c11
gcc main.c -std=c11 -pthread
I get an implicit declaration:
main.c:9:2: warning: implicit declaration of function ‘pthread_kill’ [-Wimplicit-function-declaration]
With -std=c99
gcc main.c -std=c99 -pthread
Same result as -std=c11:
main.c:9:2: warning: implicit declaration of function ‘pthread_kill’ [-Wimplicit-function-declaration]
With -std=c90
gcc main.c -std=c90 -pthread
It simply works without any errors/warnings.
Thank you for your feedbacks.
If you use a Posix feature, you need to define an appropriate feature test macro. See man feature_test_macros or the Posix standard.
If you don't define _POSIX_C_SOURCE to an appropriate value (depending on the minimum Posix level you require), then interfaces from that and subsequent Posix standards will not be defined by standard library headers.
If you need Posix.1-2008, for example, you need to do this:
#define _POSIX_C_SOURCE 200809L
#include <stdlib.h>
#include <pthread.h>
#include <signal.h>
int main(int argc, char *argv[])
{
pthread_t th = NULL;
pthread_kill(th, 0);
return 0;
}
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.