Momentan verwende ich boost::program_options , um eine Konfigurationsdatei auf dem BeagleBoard (ARM-basierter Prozessor) zu analysieren. Mein Programm ist multi-threaded und mit den Bibliotheken boost 1.45 multithreaded verknüpft.
Mein Programm scheint nur zu hängen, wenn die Konfigurationsdatei analysiert wird
%Vor%Das Programm hängt vor dem Ausdruck "Nach dem Hinzufügen von Optionen". Wenn ich das Programm über gdb laufen lasse, höre es auf und mache eine Rückverfolgung, es zeigt nur an, dass es in der Zeile vor dem Kommentar "Niemals kommt hier" war. Die Oberseite des Backtrace hat es einfach bei
%Vor%... (lassen Sie mich wissen, wenn Sie mehr wollen)
Irgendwelche Gedanken? Dieses Programm funktioniert auf einer x86-Maschine
Bearbeiten: Weitere Informationen, dies scheint nicht zu geschehen, wenn die Optimierungen ausgeschaltet sind (kompiliert mit -O2 wird das ziemlich konsistent auftreten).
Edit2: Eine weitere Analyse zeigt, dass dies immer noch mit den Optimierungen off -O0 passiert.
Dies könnte ein Problem sein, das damit zusammenhängt, wie Sie Boost und Ihre Anwendung aufbauen. Die Mutex-Lock-Implementierungen unterscheiden sich, wenn Sie für den Daumen und ohne Daumen kompilieren. Stellen Sie sicher, dass Sie sowohl die Anwendung als auch die Boost-Bibliothek mit den gleichen Daumeneinstellungen kompilieren.
Hier ist ein Beispiel user-config.jam Ich benutze, um boost :
Beachten Sie, dass ich in diesem Beispiel nicht mit aktiviertem Daumen kompiliert habe.
Tags und Links c++ boost arm boost-program-options