std::chrono::high_resolution_clock funktioniert nicht mit Linux (SteamOS)

Doofkopp

Hallo

Ich möchte ermitteln, wie lange eine Funktion zur Abarbeitung benötigt. Der C++-Code wird für Windows (Visual Studio), OSX (XCode) und SteamOS(g++) in Form einer Funktionsbibliothek kompiliert.

Kompilieren kann ich für alle drei Betriebssysteme fehlerfrei, aber die Ausführung klappt nur unter Windows und OSX. Linux (SteamOS) will nicht.

Andere Funktionen in der Funktionsbibliothek, die nichts mit Zeitmessung zu tun haben, funktionieren ebenfalls unter Linux einwandfrei. Nur die Zeitmessung macht dort Probleme.

Hier ist der Code:

#include <ctime>
#include <iostream>
#include "stdio.h"
#include <thread>
#include <chrono>
#include "TimeMeasure.h"

typedef std::chrono::high_resolution_clock HighResClock;

float getTimeDiff(HighResClock::time_point* EndTime, HighResClock::time_point* StartTime)
{
   std::chrono::milliseconds ms = std::chrono::duration_cast<std::chrono::milliseconds>(*EndTime - *StartTime);
   return (float)ms.count();
}

float rechneMal()
{
   HighResClock::time_point StartTime = HighResClock::now();
   // jetzt irgendwas in der Funktion machen und danach nochmal die Zeit messen
   std::this_thread::sleep_for(std::chrono::milliseconds(387));

   HighResClock::time_point EndTime = HighResClock::now();
   float timeDiff = getTimeDiff(&EndTime, &StartTime);

   return timeDiff;
}

Falls es jemanden interessiert, so sieht das Shell-Script unter Linux aus:

#!/bin/bash
clear
# für 32bit den Parameter -m64 entfernen
g++-4.9 -std=c++11 -Wall -shared -fPIC -m64 -o \
\
libTest.so \
TimeMeasure.h \
TimeMeasure.cpp \

Aha, "will nicht", "macht Probleme". Bei einer so konkreten Fehlerbeschreibung wird dir sicher gleich geholfen ...

Doofkopp

Oh, sorry. War keine Absicht.

Also: Wenn das Hauptprogramm gestartet wird und eine Funktion aufruft, die in der Funktionsbibliothek verfügbar ist, bleibt die Ausführung genau an der Stelle stehen, wo die Zeitmessung beginnen soll. Besser kann ich es leider nicht beschreiben.

Doofkopp schrieb:

Also: Wenn das Hauptprogramm gestartet wird und eine Funktion aufruft, die in der Funktionsbibliothek verfügbar ist,

Wo ist der Zusammenhang zum gezeigten Code?

Doofkopp schrieb:

bleibt die Ausführung genau an der Stelle stehen, wo die Zeitmessung beginnen soll.

Wie hast du das festgestellt?

Doofkopp

Die Bibliothek wird zusammen mit einem Linux-Build von Unity3D verwendet.
Unity selbst läuft genau bis dann weiter, bis die exportierte Funktion "rechneMal" gestartet wird.
Irgendwelche grafischen Ausgaben werden zunächst angezeigt. Wird dann die Funktion "rechneMal" von Unity aus gestartet, werden alle restlichen grafischen Ausgaben nicht mehr angezeigt. An irgendwas scheint sich Unity3D zu stören.

Durch schrittweise Auskommentierung und ständiger Neukompilierung konnte ich das Problem genau auf die Zeitmessung eingrenzen.

Die Funktion "rechneMal" wird in der Bibliothek so zur Verfügung gestellt:

#ifdef Platform_Linux
#define DLL extern "C"
#endif

DLL float rechneMal();

hustbaer

Versuch mal ob du das ganze mit einer alleinstehenden .exe nachvollziehen kannst.
Bzw. du kannst auch nen Dump vom laufenden Prozess ziehen und dann gucken wo er steht.

Doofkopp

Eine *.exe? Unter Windows und OSX klappt das ja alles. Nur unter Linux nicht.
Aber wenn Du eine Konsolenanwendung für Linux meinst, versuche ich das mal.

Doofkopp

OK, ging doch schneller als gedacht.
Die Konsolenanwendung unter Linux funktioniert korrekt. Die Zeitmessung klappt.

Jetzt bin ich komplett ratlos. Ich könnte evtl. mal noch die Konsolenanwendung direkt unter SteamOS starten.
Hatte jetzt nur Ubuntu in einer VM laufen.

Doofkopp

Unter SteamOS gibt es einen Fehler, der im Terminal so aussieht:

./a.out: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version 'GLIBCXX_3.4.19' not found (required by ./a.out)

hustbaer

Na dann geht ihm wohl ne DLL ab.
(Sorry, konnt' mir jetzt nicht verkneifen DLL statt SO zu schreiben )

Du erzeugst eine Art Plugin für die Spieleengine?
Wurde die mit der gleichen g++-Version und auch mit c++-11 übersetzt?

hustbaer

Bei ner extern "C" Funktion die keine Parameter nimmt und nen float zurückgibt sollte das doch eigentlich noch egal sein, nen?
OK, Exceptions sollte sie auch keine werfen.

Doofkopp

So ein Plugin ist nicht weiter wild. Kompiliert habe ich es mit g++ 4.9.
Und da zickt anscheinend SteamOS. Ubuntu hat damit kein Problem.

firefly

Doofkopp schrieb:

So ein Plugin ist nicht weiter wild. Kompiliert habe ich es mit g++ 4.9.
Und da zickt anscheinend SteamOS. Ubuntu hat damit kein Problem.

Wenn das ein plugin für unity3D ist, dann sollte das plugin mit der gleichen compiler version kompiliert werden wie unity3D (Sollte eigentlich von unity3D irgendwo dokumentiert sein)

Doofkopp schrieb:

So ein Plugin ist nicht weiter wild. Kompiliert habe ich es mit g++ 4.9.
Und da zickt anscheinend SteamOS. Ubuntu hat damit kein Problem.

Die libstdc++ ist auf dem SteamOS zu alt (d.h. unterstützt den g++4.9 nicht). Ob man c++-03 und c++-11 mischen kann weiß ich nicht.

hustbaer schrieb:

Bei ner extern "C" Funktion die keine Parameter nimmt und nen float zurückgibt sollte das doch eigentlich noch egal sein, nen?
OK, Exceptions sollte sie auch keine werfen.

Wenn der enthaltene C++-Code nicht unterstützt wird, hilft es nicht.
Ansonsten kann ich es nicht sagen.

Doofkopp

Ist es denn nicht gerade Sinn und Zweck von Plugins, dass die verwendete Sprache bzw. deren Version keine Rolle spielt?
Unter Windows kann ich ja auch eine DLL mit Delphi erstellen und die mit Unity verbinden. Was ich auch schon getan habe.

Doofkopp

Die Bemerkung von manni66 erscheint mir nachvollziehbar. Denn als ich den Code der Bibliothek als Konsolenanwendung kompiliert hatte, funktionierte es reibungslos unter Ubuntu, unter SteamOS jedoch nicht.

Ich werde einfach warten müssen, bis sich Valve bemüht hat, da noch Aktualisierungen einzubinden.

hustbaer

Ich weiss nicht was "enthaltener C++ Code wird nicht unterstützt" bedeuten soll.
Dem Freun Kollegen SteamOS geht nen SO ab. Umstellen auf Runtime statisch linken und die Sache sollte gegessen sein.
Nicht

Bzw. ansonsten das GLIBCXX_3.4.19 File halt einfach mit ausliefern (+ evtl. weitere nötige SOs).

Valve kann ja schliesslich nicht alle paar Tage nen SteamOS Update machen, nur weil irgend ein Compiler wieder ne neue Runtime Library Version bekommen hat.