2013-04-14 16 views
11

Próbuję przenieść duży projekt, który intensywnie wykorzystuje funkcje C++ 11, do Raspberry Pi. Projekt używa CMAKE i używam crosstool-ng do kompilacji krzyżowej. Zainstalowałem zależności od Pi i skopiowałem je lokalnie, i udało mi się zdobyć CMAKE, aby je znaleźć. Część kodu buduje się poprawnie i produkuje wyjście ARM. Jednak większość kodu kończy się niepowodzeniem z mylącym wynikiem GCC, który jestem pewny, że ma do czynienia z obsługą C++ 11/template. Na przykład, pojawiają się błędy tak:Kompilacja krzyżowa kodu C++ 11 dla Raspberry Pi

  • error: 'mutex' in namespace 'std' does not name a type (dany plik zawiera < wątek > i ten błąd zniknie jeśli ja także <mutex>, a nie wymóg na x86 Ubuntu)

  • error: expected class-name before '{' token (linia przed {brzmi: template<typename _Res> class __basic_future : public std::__future_base)

  • error: '__result_type' does not name a type (to prawdopodobnie dzieje się z powodu błędu powyżej)

Te błędy wyglądają tak, jak kompilator ARM g ++ po prostu nie lubi zbyt wielu szablonów. Używana wersja g ++ to arm-unknown-linux-gnueabi-g++ (crosstool-NG 1.18.0) 4.7.3 20130102 (prerelease).

Czy ktoś może wskazać mi właściwy kierunek?

Edycja: Oto co g ++ wygląda na jeden z plików w ps:

arm-unknown-linux-gnueabi-g++ -DprojectCore_EXPORTS -fPIC 
-I/home/sagar/workspace/RaspberryPi/target_env/usr/include 
-I/home/sagar/workspace/RaspberryPi/target_env/usr/include/freetype2 
-I/home/sagar/workspace/RaspberryPi/target_env/usr/include/glib-2.0 
-I/home/sagar/workspace/RaspberryPi/target_env/usr/lib/arm-linux-gnueabihf/glib-2.0/include 
-I/home/sagar/workspace/RaspberryPi/target_env/usr/include/gdk-pixbuf-2.0 
-I/home/sagar/workspace/RaspberryPi/target_env/usr/include/gtk-2.0 
-I/home/sagar/workspace/RaspberryPi/target_env/usr/lib/arm-linux-gnueabihf/gtk-2.0/include 
-I/home/sagar/workspace/RaspberryPi/target_env/usr/include/cairo 
-I/home/sagar/workspace/RaspberryPi/target_env/usr/include/pango-1.0 
-I/home/sagar/workspace/RaspberryPi/target_env/usr/include/atk-1.0 
-I/home/sagar/workspace/RaspberryPi/target_env/usr/local/include 
-I/home/sagar/workspace/RaspberryPi/target_env/usr/include/eigen3 
-I/home/sagar/workspace/RaspberryPi/target_env/usr/include/flann 
-I/home/sagar/workspace/project/include -std=c++0x -Wall -Werror -Wno-deprecated -fPIC -g -O4 
-o CMakeFiles/projectCore.dir/src/project/Core/Memory/Array2D.C.o -c /home/sagar/workspace/project/src/project/Core/Memory/Array2D.C 
+0

'-std = C++ 11' może? –

+0

@BartekBanachewicz Dodałem polecenie g ++ wygenerowane dla jednego z plików. -std = C++ 0x jest tam i myślę, że to jest to samo, co C++ 11 w tym momencie. – sagargp

+1

Dobrze 'std :: mutex' ma być zdefiniowane w' '(lub [tak to tutaj mówi] (http://en.cppreference.com/w/cpp/thread/mutex)), więc nie myślę, że to błąd - jeśli w ogóle, to błąd polega na tym, że wersja x86 zawiera nagłówki, o które nie prosiłeś, ale nie pamiętam, w jakim stopniu jest to dozwolone. Ale dodanie go nie złamie x86, prawda? Czy włączyłeś '' dla pozostałych? – Rup

Odpowiedz

2

tylko rzeczy, myślę, że to:

  • ustawić -std=c++0x param do g++ compiler
  • łącza Pthread (-lpthread)
  • Musisz być pewien, że kompilujesz się pod kątem armv6
1

Pozwól mi zacząć od stwierdzenia, że ​​nie jestem pewien co do poprawki tego błędu. Ale widziałem podobny błąd podczas pracy z C++ w RPi dla dużego kodu przetwarzania obrazu. Nie mogłem tego naprawić, instalując wszystkie zależności w czasie. Zamiast tego w końcu przenieśliśmy cały kod do chmury, na której był uruchomiony kod Windows Server Edition/Windows 7, gdzie został dobrze skompilowany. Po prostu obejść ten pomysł, jeśli jesteś ograniczony czasowo!