2013-04-21 21 views
5

Próbuję przekompilować duży projekt dla Raspberry Pi. Używam toolchaina zbudowanego przez crosstool-ng, gcc w wersji 4.7.3. Kompilacja dławi, gdy widzi std :: shared_future. Otrzymuję ten błąd:std :: shared_future na toolchain Raspberry Pi

test.cpp:5:27: error: aggregate 'std::shared_future<int> xxx' has incomplete type and cannot be defined 

A oto plik źródłowy, który generuje ten błąd:

#include <future> 

int main() 
{ 
    std::shared_future<int> xxx; 
    return 0; 
} 

Ten sam plik źródłowy kompiluje powodzeniem na Rapsberry samego Pi. Czy jest to błąd w zestawie narzędzi crosstool? Czy jest w pobliżu praca? Jak mogę to skompilować?

+0

Czy jesteś pewien, że odpowiednie flagi są przekazywane do kompilatora? Czy w ogóle masz wsparcie C++ 11? – Thibaut

+1

Czy można skompilować 'std :: future',' std :: async' lub 'std :: thread'? – juanchopanza

+0

Przepraszam, zignorujcie mój poprzedni komentarz, właśnie uświadomiłem sobie, że kompilator narzekałby na to, że jeśli C++ 11 nie było w ogóle. – Thibaut

Odpowiedz

2

Rozwiązałem ten problem z pomocą @backlash i osób z #gcc na Freenode. Crosstool-NG budował toolchain dla armv7, podczas gdy kompilator Raspberry Pi kompilował dla armv6. Zmiana "Poziomu architektury" (Opcje celu> Poziom architektury) na armv6 pozwoliła mi skompilować kod przykładowy opublikowany w moim oryginalnym pytaniu. Ta opcja dodaje --with-arch=armv6 do flag konfiguracji dla gcc. Mam nadzieję, że to pomoże komuś w przyszłości.

3

Aby shared_future klasę realizacji, a nie tylko oświadczenie do przodu, trzeba mieć następujący warunek preprocesora równe true: #if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1) && (ATOMIC_INT_LOCK_FREE > 1)

Według poprzedniej odpowiedzi @juanchopanza, wydaje się, że masz następujące części warunek równy true: if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1), ponieważ jest to wymagane do wdrożenia klasy thread.

Ostatecznie możemy powiedzieć, że ta część warunku jest fałszywa ATOMIC_INT_LOCK_FREE > 1.

+1

Dlaczego nie byłaby to prawda? Czy istnieje flaga kompilatora, którą powinienem przekazać? Zauważ, że ten sam kod kompiluje się na samym rPi. – sagargp

+2

Wygląda na to, że jest różnica między twoim rodzimym kompilatorem i kompilatorem krzyżowym, więc powinieneś spróbować dowiedzieć się, dlaczego się nie zgadzają. –

+2

'ATOMIC_INT_LOCK_FREE> 1' może być fałszywą przyczyną złej konfiguracji podczas generacji crosstool-ng. Tak więc myślę, że powinieneś przebudować swój toolchain z konfiguracją, która sprawia, że ​​'ATOMIC_INT_LOCK_FREE> 1' jednak nie wiem jak. – backlash

Powiązane problemy