Probleme mit nanosleep() in Eclipse

Erik Wolf schrieb:

> Ich könnt mir vorstellen das es an irgendwlechen Projekteinstellungen
> liegt das Eclipse evtl. die time.h nicht finden kann.

Wenn der Compiler time.h nicht hätte finden können, hättest du eine 
entsprechende Fehlermeldung bekommen.

Schau doch mal in time.h hinein, such dir die struct timespec und sieh 
nach, wie die Member wirklich heißen.

Karl Heinz Buchegger schrieb:
> Wenn der Compiler time.h nicht hätte finden können, hättest du eine
> entsprechende Fehlermeldung bekommen.

Klar, aber der hat seine eincompilierten Pfade, auf denen er das
sucht.  Die müssen nicht mit dem übereinstimmen, was Eclipse kennt.
Eclipse möchte das aber gern kennen, (offenbar) damit es im Debugger
weiß, welcher Datentyp sich dahinter verbirgt.

Man kann dem Compiler eine zusätzliche Option -v beim Compilieren
mitgeben, dann zeigt er an, welche Pfade er für include-Dateien
sucht.  Außerdem kann man sich mit dem Schalter -E das Zwischen-
ergebnis nach dem preprocessing ausgeben lassen, dort stehen die
tatsächlichen Pfadnamen dann drin, sodass man erfahren sollte, durch
welche Datei er das <time.h> aufgelöst hat.

Karl Heinz Buchegger schrieb:
> Wenn der Compiler time.h nicht hätte finden können, hättest du eine
> entsprechende Fehlermeldung bekommen.

Genau, vom Compiler habe ich keiner Fehlermeldung bekommen. Der macht es 
offensichtlich richtig, zumal die Funktion ja auch wie gewollt 
funktioniert. Nur Eclipse leider nicht.

> Schau doch mal in time.h hinein, such dir die struct timespec und sieh
> nach, wie die Member wirklich heißen.

Habe ich gemacht.

1

struct timespec

2

  {

3

    __time_t tv_sec;    /* Seconds.  */

4

    long int tv_nsec;    /* Nanoseconds.  */

5

  };

Jörg Wunsch schrieb:
> Man kann dem Compiler eine zusätzliche Option -v beim Compilieren
> mitgeben, dann zeigt er an, welche Pfade er für include-Dateien
> sucht.  Außerdem kann man sich mit dem Schalter -E das Zwischen-
> ergebnis nach dem preprocessing ausgeben lassen, dort stehen die
> tatsächlichen Pfadnamen dann drin, sodass man erfahren sollte, durch
> welche Datei er das <time.h> aufgelöst hat.

#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/include
 /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/include-fixed
 /usr/include/i386-linux-gnu
 /usr/include

Mein Eclipse sucht in genau den gleichen Verzeichnissen.

Dann musst du wohl entweder das Eclipse dazu überreden, dass es dir
ein paar Debuginformationen rausrückt, oder du lässt den ganzen Kram
durch strace laufen (Option -e trace=open sollte genügen) und siehst
nach, auf welche Dateien es alles zugreift.

Erik Wolf schrieb:
> Karl Heinz Buchegger schrieb:
>> Wenn der Compiler time.h nicht hätte finden können, hättest du eine
>> entsprechende Fehlermeldung bekommen.
>
> Genau, vom Compiler habe ich keiner Fehlermeldung bekommen. Der macht es
> offensichtlich richtig, zumal die Funktion ja auch wie gewollt
> funktioniert. Nur Eclipse leider nicht.

Ah mein Fehler.
Das hab ich überlesen.
Entschuldigung.

Vergiss die Sache mit time.h  Jörg hat das IMHO bereits korrekt 
diagnostiziert: Diskrepanz zwischen den Include-Verzeichnissen des 
Compilers und der IDE

Ok, hab jetzt noch ein bisschen weiter geschaut. Es handelt sich bei der 
Geschichte offensichtlich um einen Eclipse Bug.

Lösung: Einfach ignorieren.