Hallo Leute,
ich habe folgendes Problem:
Ich habe mir einen Makefile geschrieben der anhand von Suffix-Regeln entscheidet welches Kommando ausgeführt werden soll.
Das funktioniert auch so wie es soll.
Jetzt ist es aber so, dass ich meine object-Dateien in ein anderes Verzeichnis als die source-Dateien ablege. Wenn ich nun wieder "make" aufrufe wird wieder alles durchkompiliert, obwohl gar nichts getan werden müsste.
Kann mir jemand sagen wie ich 'make' sagen kann wo die objects-Dateien liegen oder muss ich da was anderes machen?
Habe schon probiert sie mit 'touch' zu markieren, hat aber zu keinem Erfolg geführt.
Gruß Meaculpa
und den gpointer auch nach int ( oder gint ) zurückgecastet ?
da gibts auch makros für inner glib: GPOINTER_TO_INT().
ps. endlich mal einer, der auch mit GObjects rummacht
ach ja sehe grade dass du die addresse des int übergibst.
eigentlich will man nen gpointer haben.
am besten beim reinschieben nach gpointer casten mit (GINT_TO_GPOINTER()),
und wenn wir schon beim casten sind: die callback funktion am besten
auch mit G_CALLBACK (func) casten.
so haben mir das ein paar gimp/gtk entwickler beigebracht
hi,
Ich hab da ein grösseres Anliegen. Ich weiss einfach nicht wie ich mit g_signal_connect nen einfachen int wert übergeben kann, also beispielsweise:
int test = 5;
g_signal_connect (G_OBJECT(knopf),"released",
G_CALLBACK(test_func),test);
das funktioniert net, ich hab auch schon dies versucht:
void test_func(GtkWidget *widget,
gpointer g)
{
...
}
int test = 5;
g_signal_connect( GTK_OBJECT( knopf ), "released",
G_CALLBACK(test_func ),&test );
dann hab ich zwar die adresse, ich bekomm den wert aber net raus..
wäre super wenn ihr mir da helfen könntet
mfg
Sui_the_Doc
@CarstenJ,
danke für deine schnelle Antwort.
Ich war der Meinung das man den Samba Daemon genau wie bei z.B.
vsftpd via xinetd starten sollte. Für den Anfang versuche ich mal
ohne dieses Admin-Tool auszukommen. Ich will ja immerhin was lernen
und nicht gleich auf fertige Lösungen zurückgreifen.
Naja das Wochenende ist ja noch jung und ich bin es auch
also werde ich mich mal durch diese Dokumentation kämpfen.
Bye Peter.
PS: ist das etwa so das ich mehrere Verzeichnisse nicht auf einmal erzeugen kann z.B. /srv/www/htdocs/ vorhanden und /srv/www/htdocs/hallo/hallo/hallo/ soll erzeugt werden ?
genau so ist es.
perror() gibt einem da auch meist Tips
Solaris'dUKe schrieb:
Mit Threads hingegen kann ich gemeinsame Ressourcen nutzten...
Wieso benutzt du dann ne IPC-queue? Der Sinn dieses Teils besteht doch hauptsächlich darin, dass ich zwischen Prozessen, die nicht verwandt sind, kommunizieren kann, weil ich sie über den Schlüssel identifizieren kann.
Auf Dein eigentliches Problem zurückzukommen. Ich bin mir nicht sicher und sitze hier gerade an der falschen Maschine um das ganze zu testen, aber probier mal folgendes als sighandler:
void mySigHandler(int sig){
pthread_kill(pthread_self(), sig);
}
Die Funktionsweise sollte klar sein. Sighandler einfach für SIGALRM registrieren. Dem Thread in welchem der Handler ausgeführt wird, wird dann das Signal geschickt.
improvisator schrieb:
Gibt es eine Möglichkeit mein Programm so zu starten, dass es auf Konsoleneingabe und auf mein fifo.in hört?
schau mal nach der Funktion select(...).
Andere Möglichkeit auch mehrere Threads oder Prozesse zu benutzen. Kommt halt drauf an was Du machen willst. Ich denk aber dass select(...) Deine Wünsche erfüllen wird.
Hi Forum!
Muß ein Treiber, der die Kernelsourcen verwendet, aber dann auf 'ne Installationsdiskette zum on-the-fly-Verwenden bei einer Distro-Installation kommt, unbedingt mit einem 64 Bit Kernel kompiliert werden, wenn das System, auf das installiert werden soll, ein 64Bitter ist?
Bzw. zu meinem Problem: Ich habe einen Athlon 64, und eine SATA Platte.
Der SATA Treiber wird von Suse 9.0 64 nicht erkannt (und demnach auch keine Platte).
Ich bräuchte halt einen SATA Treiber vom VIA VT8237 Chipsatz. Als Binary ist der aber nur für RedHat verfügbar.
Eine selbst-kompilierbare Version gibt es, ich kann sie aber nicht kompilieren, solange ich kein Linux installiert hab'.
Ein Teufelskreis!
Oder noch anders: Hat jemand zufällig die Muße mir meinen Treiber zu kompilieren?! Von VIA gibt's das Zeug hier: http://www.viaarena.com/?PageID=297#ATA
Auf kernel.org halt die Kernelsourcen. Suse 64 hat IIRC 2.4.21.
Oder gibt's irgendwo 'ne Binary Version im Netz, die ich mit meinen Suchbegriffen noch nicht aufgespürt habe?!?
Wenn Dein Vater alle Kindprozesse erzeugen soll, wird es glaube ich sehr schwer, Kind1 mit Kind2 kommunizieren lassen. Dann müsstest Du bevor Du das erste mal forkst alle Pipes anlegen und dann nach dem Forken bei jedem neuen Kindpozess die ungenutzten Pipe-Enden für dieses Kind schliessen und nach dem Du alle Kinder geforkt hast schliesslich alle unbenutzten Enden des Vaterprozessen schliessen. Du musst also immer alle Filediskreptoren, bis auf 2 schließen. Damit liesse sich ein echter Ring aufsetzen. Ein genereller Nachteil an einem solchen (einfachen) Ring ist allerdings, dass wenn ein Prozess hängt, ist der gesamte Nachrichtenaustausch tot.
Alternativ könntest Du für jeden Kindprozess jeweils 2 Pipes anlegen (also 4 fd's), über die die Kinder jeweils mit dem Vater bidirektional kommunizieren können und der Vater dann als Dispatcher agiert. Physikalisch ist das natürlich kein Ring mehr, aber ein entsprechendes Protokoll könnte daraus einen logischen Ring machen.
Wenn dieser Weg Dir brauchbarer erscheint, solltest Du Dir allerdings zwecks evtl. großen zu übermittelnden Nachrichten noch Gedanken über SharedMemory und Semaphoren machen, kann dann nämlich die Performance erheblich steigern.
Bringt doch bitte nicht die OS-Ebene mit stdio.h durcheinander. Filedeskriptoren bekommt man vom Kernel mittels open, man nutzt sie mit read, write usw. und schließt sie mit close. Das sind einfache Ganzzahlen. Die stdio.h-Funktionen (fopen, fclose, fgetc etc.) bilden eine gepufferte Schicht darüber. Man bekommt von fopen einen Zeiger auf ein FILE-Objekt, keinen Filedeskriptor.
Eine Aussage über Filedeskriptoren bringt dich also überhaupt nicht weiter, wenn du mit der stdio arbeitest.
Wenn mein Programm mitten im Ablauf unterbrochen wird, möchte ich alle offenen File-Descriptoren mit fclose(FILE *stream) schließen.
Nun muss ich herausfinden ob mein Descriptor noch gültig ist, denn wenn ich er schon vorher geschlossen wurde und ich ihn nun wieder schliesse bekomme ich ein Seg-fault.
Hallo danke für die Antworten.
Ich denke, daß ich xLib nehmen werde, da es mir nur darum geht, irgendwelche Primitive zu zeichnen, also nur Polylines, Lines usw.
Gibt es dazu ein gutes Buch?
Danke!
Es gibt recht viele Exploits, die es dem Angreifer ermöglichen, seinem Code als Root-Prozess zum laufen zu bringen. Dementsprechend gibt es aus jede Menge ML, die sich gerade mit solchen Themen auseinandersetzen.
Ein selbstkompilierter Kernel kann etwas bringen weil:
- die Standardkernel in den Distris meistens Komponenten/Module enthalten, die man bei eigener Hardware-Komponenten-Auswahl nicht braucht -> kleinerer Kernel
- Neuere GCCs den Code besser optimmieren können -> schnellerer Kernel
- Der GCC den Code besser auf die lokalen Gegebenheiten optimieren kann -> schnellerer Kernel
- Man neuere Optionen im Kernel haben möchte (z.B. Kernelthreads in der 2.6er Fassung etc.) -> Fuchsschwanzkernel
- Bugs in den neuen Sourcen gefixt wurden -> sicherer Kernel
- Neue Hardware manchmal neuere Optionen im Kernel benötigt und man diese nicht immer per Modul nachladen möchte -> Fuchsschwanzkernel
Dann gibt es sicherlich noch etliche weitere Gründe, die mir gerade nicht einfallen.
MfG Kimmi
die meisten Distribution bieten PowerPC Versionen an. Bei SuSE zB. erhälst du gleich ein Handbuch, was du bestimmt brauchen wirst, wenn du dich nicht mit Linux auskennst!
mach dir lieber die suse 9.1 drauf. die kommt zwar normalerweise erst in einer woche, aber in manchen läden gibt es die schon. oder warte auf die ftp-installation von suse!