Ich habe ein sehr interessantes Linux-tool gefunden, dass auch Pluginunterstützung hat. Ich würde auch gerne ein Plugin schreiben, aber ich bekomme einfach keine "saubere" Bibliothek (ein sauberes Projekt hin) hin, bzw. es ist doch alles sehr um die Ecke gedacht.
Ich benutze KDevelop 3.5.0.
Die Plugins sitzen in tool/plugins/name_plugin/.
Es handelt sich um libtool libraries in pkglib
Meine bisherige Lösung sieht folgendermaßen aus:
1. Quellcode extrahieren
2. Mit KDevelop als Generic C Application (automake-based) importieren
3. Im Automake-Manager zu den Plugins gehen und dort den Quellcode eines Plugins in meinen Code umschreiben.
4. Mit Hilfe vom Automake-Manager von KDev. headerdateien aus ../../include/ aus dem Pluginverzeichnis heraus.verlinken
5. Manuell zusätzliche header durch ln -s ../../include/missing aus dem Pluginverzeichnis heraus.verlinken
6. ganzes Projekt ./configure dann speziell nochmal das (mein) target plugin erstellen
Ich finde das alles ziemlich umständlich und irgendwie habe ich das gefühl, dass die OpenSource-Welt bestimmt einen Weg benutzt der wesentlich komfortabler ist bzw.. bei dem sich der relevante plugin-source auch besser aus dem restlichen Projekt herauslösen lässt um ihn zum beispiel zu publizieren ... Gibt es da etwas ?
Also in der man-page von sem_open ist ein Verweis auf die man-page von sem_overview. Und dort steht:
Linking
Programs using the POSIX semaphores API must be compiled with cc -lrt to link against the real-time library, librt.
Und wie auch daraus zu ersehen ist, heißt es einfach nur, dass das zu erstellende Programm die Bibliothek rt benutzen soll. Mit "ldd einprogram" kannst du dir alle Bibliotheken ausgeben lassen, die ein Programm benötigt.
Shapeshifter schrieb:
Hi,
Also wenn ich diese kleine bash Datei ausführe passiert einfach gar nichts, er beschwert sich nicht mit einer Fehlermeldung o.ä., führt die beiden Zeilen aber auch nicht aus.
Ich kenn mich nicht allzu gut mit diesen Scripts aus; ich dachte bisher ich kann da alle möglichen commands reinpacken die ich sonst auch in der shell manuell ausführe.
Ich probiere die letzte gepostete Variante mal aus, danke für den Tipp.
Das script wird erfolgreich ausgeführt. Nur das problem ist, wenn du ein script-file ausführst wird das script in einer subshell ausgeführt.
Um in der aktuellen shell die ENV-Variable zu ändern musst du entweder, wie schon gesagt den inhalt des scripts in die .bashrc einfügen. Oder per source <script-file> den Inhalt in die aktuelle shell zu exportieren.
$CC enthält den Pfad zur Executable des Compilers, also zB CC=/home/test/gcc-4.1.2/bin/gcc . Da nur den Pfad zu einem Verzeichnis reinzupacken, hilft Dir wohl nicht. Und im Makefile musst Du natürlich auch CC verwenden, statt einfach gcc.
Zu Fortran: http://gcc.gnu.org/wiki/GFortran#manuals
Sorry, ich habe im Inet, auf diversen Seiten und Tutorials geschaut, und da stand das nicht, auf die naheliegenden man-Pages bin ich nicht gekommen.
MEA CULPA ... tut mir leid.
Danke für die Antwort
Gruss Alex
Für alle die Lösung:
Das Problem nennt sich Most Significant Byte first. Eine Bestimmung in der Netzwerktechnik.
ntohs ist in diesem Falle das Zauberwort!
Besteht ein Wert[*] aus mehreren Bytes, wird auf 80x86 Prozessoren das niederwertige Byte vorangestellt (Least Significant Byte first), während man sich im Internet auf die umgekehrte Byteordnung geeinigt hat (Most Significant Byte first). Um von Rechner- auf Netzwerk-Ordnung zu konvertieren, benutzt man die htons() bzw. htonl() Funktionen; umgekehrt benutzt man die ntohs() bzw. ntohl() Funktionen.
htons() und ntohs() konvertieren short integer, die beiden anderen Funktionen konvertieren long integer.
unsigned long int htonl( unsigned long int hostlong );
unsigned short int htons( unsigned short int hostshort );
unsigned long int ntohl( unsigned long int netlong );
unsigned short int ntohs( unsigned short int netshort );
unter linux im header netinet/in.h
// base pointer
const u_char *packet = (const u_char*)ppacket;
// ehternet-pointer
//ether_header *eptr = (ether_header *) packet;
// compute ip-header
sniff_ip *ip = (sniff_ip*) (packet + SIZE_ETHERNET );
u_int size_ip = IP_HL(ip)*4;
// compute tcp-header data
sniff_tcp *tcp = (sniff_tcp*)( packet + SIZE_ETHERNET + size_ip );
u_int size_tcp = TH_OFF(tcp)*4;
long data_length = (ntohs(ip->ip_len) - ( size_ip + size_tcp ));
printf("\nProcess (new) tcp/ip package %i, length %i", (int)packet_counter, (int)data_length);
PS: Für den Port braucht ihr das Ebenfalls. ntohs(tcp->th_sport) / ntohs(tcp->th_dport).
Gruß jayjay
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum Linux/Unix verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?
Dieses Posting wurde automatisch erzeugt.
was du in einen socket reinschreibst, kommt ja nicht wieder heraus, wenn du davon liest. das mit dem select sollte egal sein. mit select erkennst du im prinzip nur, ob du daten schreiben oder lesen kannst. wenn du daten schreibst, obwohl select das im einen thread noch nicht "erlaubt" hat, wird write wohl lange blockieren, nehm ich an. aber ich muss gestehen, dass ich sowas noch nie ausprobiert habe. wenn du mit select auf daten wartest, ist das komplett egal, wenn du währenddessen daten reinscheibst. lesen und schreiben hat im prinzip auf einem socket nichts miteinander zu tun.
http://gcc.gnu.org/onlinedocs/libstdc++/27_io/howto.html#11
Droogandleader schrieb:
strcpy(m_cam_file,"/dev/video0");
m_cam_stream = new std::ifstream( m_cam_file);
Was machst du da mit new und strcpy? Schaut ja schrecklich aus.
./ schrieb:
nun wie gesagt mbmon war eigentlich bei Freebsd 6.2 und mein rechner das beste progi was brauchbare und vergleichbare daten ausgegeben hat, wie die vom Bios.
ksenors usw ging damals nicht wo ich das schon mal probiert hatte.
sorry hatte Nick vergessen
Weder X noch OGL sind von sich aus Threadsafe X bietet nach XInitThreads() allerdings einen eigenen Locking-Support.
Von OpenAL kann ich's nicht sage, sollte aber hier keine Rolle Spielen, RakNet verwendet selbst Threads und hat nur die Einschränkung, dass man den zugriff Locken muss.
An sich kann es kaum zu races kommen, höchstens wenn ich irgendeinen X / OGL Buffer nicht rechtzeitig geflusht habe
Nun habe jetzt was im netz gefunden da soll man mit
box(fenster, 0, 0) auch eine Linie umherziehen.
Geht auch und die warung ist nun weg.
Gebe aber zu das ich nicht ganz verstehe warum er nun mit 0, 0 auch die linie zieht
Inzwischen hat sich doch eine Loesung gefunden
http://www.easysw.com/~mike/serial/serial.html#5_1_1
Weiter unten wird das bei "Chapter 4, Advanced Serial Programming" erklaert. Naja ist bestimm nicht fuer sowas gedacht wie ich es benutze aber es funktioniert immerhin.
Gr4n@ttr
ºgrimmsenº schrieb:
Also wenn ich meine CPU-Frequenz zur Laufzeit ändere, sehe ich das auch in cpuinfo - sofort.
Ja, weil /proc als Interface zum Kernel fungiert. Die Daten werden eben abgefragt, wenn Du die Dateien dort öffnest. Dazu müssen nicht ständig vom Kernel irgendwelche echten Dateien auf der Festplatte aktualisiert werden.