Hacking, Spiele, Physik und Politik

Quick Cluster Overview jetzt auf Gitorious

Da ich Quick Cluster Overview (QCO) die Tage für ein Projekt meiner universitären Arbeitsgruppe wieder rauskramen musste habe ich genutzt um den Quellcode gleich mal auf Gitourious zu schieben. Die URL der Projektseite lautet http://gitorious.org/qco.

Ich habe lokal noch einige Aktualisierungen und Ideen herumliegen. Ich hoffe ich finde die nächsten Tage mal die Zeit diese auch einzupflegen.

OpenCL und #include

Jeder der das erste mal versucht in einem OpenCL-Kernel eine Headerdatei mit #include "header.h" einzubinden scheitert für gewöhnlich mit einer Fehlermeldung im Stiele von catastrophic error: cannot open source file "header.h". Grund ist, dass der Compiler normalerweise nicht im Quellverzeichnis nach der Headerdatei sucht. Man muss dem Befehl clBuildProgram explizit den Pfad per Compileroption -I /pfad/zu/den/headern/ übergeben.

Jeder der das erste mal versucht in einem OpenCL-Kernel eine Headerdatei mit #include "header.h" einzubinden scheitert für gewöhnlich mit einer Fehlermeldung im Stiele von catastrophic error: cannot open source file "header.h". Grund ist, dass der Compiler normalerweise nicht im Quellverzeichnis nach der Headerdatei sucht. Man muss dem Befehl clBuildProgram explizit den Pfad per Compileroption -I /pfad/zu/den/headern/ übergeben. Beim Implementieren der Parameterübergabe an clBuildProgram fällt schnell auf, wieso er den Pfad nicht von alleine kennt. Ein "-I ." funktioniert nämlich spätestens dann nicht mehr, wenn man das Programm nicht im Quellverzeichnis ausführt. Man benötigt also eine Konstante mit welcher man sich den korrekten Parameter zusammenbauen kann. Dies sieht dann zum Beispiel so aus: char compiler_options[256];sprintf( compiler_options, "-I "%s"", SOURCE_DIRECTORY );err = clBuildProgram( program, 0, NULL, compiler_options, NULL, NULL); Hier ist es wichtig, dass compiler_options groß genug ist um mit jedem möglicherweise übergebenen Pfad zu funktionieren! Um den Code in unterschiedlichen Verzeichnissen übersetzen zu können definiert man diese Konstante am besten außerhalb und übergibt sie zur Compilezeit:gcc -DSOURCE_DIRECTORY="$(pwd)" -o headerTest headerTest.c Nutzt man CMake so reicht es in der CMakeList.txt die folgende Zeile hinzuzufügen:add_definitions( -DSOURCE_DIRECTORY="${CMAKE_SOURCE_DIR}" ) So weit, so schön die Theorie. Leider scheitern die Implementierungen von Apple und NVIDIA an Leerzeichen im Pfad. Da sie die Gänsefüßchen als normale Zeichen interpretieren scheitern sie mit dem angegebenen Aufruf also auch an Pfaden ohne Leerzeichen. Ein korrekter Aufruf verzichtet also auf sie, kann dann aber nicht mehr mit Leerzeichen umgehen. char compiler_options[256];sprintf( compiler_options, "-I %s", SOURCE_DIRECTORY );err = clBuildProgram( program, 0, NULL, compiler_options, NULL, NULL);

Zusätzliche Modulverzeichnisse für CMake

Patch für die Hercules DJ Console-Treiber für Linux 2.6.30 und neuer

Die Treiber für die DJ Controller von Hercules gibt es zwar in Paketen für so ziemlich alle Distributionsarten, aber leider nicht für die aktuellsten Version. Unter openSUSE 11.2 funktioniert der Treiber zunächst nicht, da dieses Kernel 2.6.31 verwendet, der Treiber aber eine ALSA-Funktion nutzen möchte welche in dieser Version aus dem Kernel flog. Ein kleiner Patch behebt das Problem indem er den entscheidenden Aufruf auf die neue Funktion ändert.

Die Treiber für die DJ Controller von Hercules gibt es zwar in Paketen für so ziemlich alle Distributionsarten, aber leider nicht für die aktuellsten Version. Unter openSUSE 11.2 funktioniert der Treiber zunächst nicht, da dieses Kernel 2.6.31 verwendet, der Treiber aber eine ALSA-Funktion nutzen möchte welche in dieser Version aus dem Kernel flog. Ein kleiner Patch behebt das Problem indem er den entscheidenden Aufruf auf die neue Funktion ändert. Hat man den Treiber nach der Anleitung auf der Webseite installiert, so kann man mit dkms status prüfen ob dieser im System erfolgreich installiert wurde. Auf System mit Kernel 2.6.30 aufwärt bekommt man hier nur die enttäuschende Meldung: hdjmod, 1.28: added. Wäre die installation erfolgreich gewesen müsste hier installed stehen. Der nächste Schritt nach dem add ist der build. Ein Blick in das Logdatei /var/lib/dkms/hdjmod/1.28/build/make.log zeigt das Problem: /var/lib/dkms/hdjmod/1.28/build/device.c:1663: error: implicit declaration of function ‘snd_card_new’ Der Patch behebt das Problem indem er für neuere Kernel den Funktionsaufruf durch auf die neue Funktion snd_card_create ändert. Um ihn anzuwenden wechselt man in das Verzeichnis /usr/src/hdjmod-1.28 und ruft dort sudo patch -p1 < /path/to/hdjmod_kernel_2.6.30.patch auf. Anschließen baut man mit sudo dkms build -m hdjmod -v 1.28 das Modul und installiert es mit sudo dkms install -m hdjmod -v 1.28. Anschließend kann man im DJ Control Panel sehen, dass der Treiber beim Anschließen der Konsole erfolgreich geladen wird. Insgesamt ein gutes Beispiel dafür, wieso man Treiber Open Source halten sollte, aber leider auch ein gute Beispiel, wieso man Treiber nicht außerhalb des Kernels pflegen sollte. >Hier kann man den Patch herunterladen<

MacPorts hinter Proxies verwenden

Sitzt man mit seinem Mac in einem Netzwerk ohne direkten Zugang zum Internet funktioniert MacPorts leider nicht automatisch mit den im System eingepflegten Proxies. Durch manuelles Setzen der Umgebungsvariablen http_proxy und RSYNC_PROXY lässt sich MacPorts aber ohne Einschränkungen nutzen.

Sitzt man mit seinem Mac in einem Netzwerk ohne direkten Zugang zum Internet funktioniert MacPorts leider nicht automatisch mit den im System eingepflegten Proxies. Durch manuelles Setzen der Umgebungsvariablen http_proxy und RSYNC_PROXY lässt sich MacPorts aber ohne Einschränkungen nutzen. Das erste Problem entsteht dadurch, dass der Befehl sudo den ausgeführten Befehl von in der Shell gesetzten Umgebungsvariablen abschirmt. Dadurch sieht der port-Befehl in der Benutzershell gesetzte Proxy-Variablen nicht und kann sich nicht mit seinen Servern verbinden. eccentrica:~ marix$ sudo port selfupdate--->  Updating the ports treeError: Synchronization of the local ports tree failed doing rsyncError: /opt/local/bin/port: port selfupdate failed: Couldn't sync the ports tree: Synchronization of 1 source(s) failed Die Lösung dieses Problems ist mit sudo eine neue Shell zu starten in der die Umgebungsvariablen gesetzt werden können. Wichtig ist hierbei, dass MacPorts auch rsync verwendet, welches nicht die http_proxy-Variable interpretiert. Deshalb muss auch die Variable RSYNC_PROXY gesetzt werden. eccentrica:~ marix$ sudo -sPassword:bash-3.2# export http_proxy=http://proxy:8080bash-3.2# export HTTPS_PROXY=http://proxy:8080bash-3.2# export FTP_PROXY=http://proxy:8080bash-3.2# export RSYNC_PROXY=proxy:8080bash-3.2# port selfupgrade An Stelle des port selfupgrade kann natürlich eine beliebige Anzahl anderer Befehle stehen. Ein weiteres Problem entsteht, wenn MacPorts Subversion verwendet um an den Quelltext des zu installierenden Programmes zu kommen. ash-3.2# port install iterm--->  Computing dependencies for iTerm--->  Fetching iTermError: Target org.macports.fetch returned: Subversion check out failedError: Status 1 encountered during processing.Before reporting a bug, first run the command again with the -d flag to get complete output. Subversion lässt sich leider nicht über Umgebungsvariablen zur Verwendung des Proxies überreden. Stattdessen muss man die Datei ~/.subversion/servers entsprechend anpassen.

Seiten

Sollten dir die Artikel auf dieser Seite gefallen und du Bitcoin für ein interessantes Experiment halten, so schicke doch eine kleine Spende an 14pQyjx5EFQCwPBkXMTz5nTcfPsnjHmWqA.

Subscribe to Marix.org RSS