Lös Fragen hier im Forum! Jeden Tag 3-4 neue Projekte, die sich schnell abschließen lassen. Und du kannst deine Ergebnisse direkt mit anderen vergleichen und falls dicke Hauer in deiner Lösung sind, bekommst du das auch mehr oder weniger unhöflich gesagt.
ich versuche es nochmal ein wenig zu verdeutlichen:
// so könnte es aussehen ohne plugin architektur
g++ -lwichtige_lib -lmeinwrapper meinprogramm.cpp
Nun ist es aber so dass ich die Klassen aus libmeinwrapper dynamisch laden möchte.
Das heißt aber für mich dass das Programm so gebaut würde
// ich weiß nichts von externen bibliotheken
g++ meinprogramm.cpp
In meinem Programm kann ich dann meinwrapper.so dynamisch laden. meinwrapper benötigt aber wichtige_lib um zu funktionieren.
Mir fällt grade nur ein, dass ich beim erstellen von meinwrapper die wichtige_lib statisch hinzulinke.
Aber statisch linken ist halt so ne sache...
Jetzt versteh ich auch nichts mehr es ging die ganze Zeit nicht Laptop
abgestürzt und jetzt kommt das :
Unblock door
:Device or resource busy
Aber er öffnet den Laufwerk und mach was ich im sage xD
AArgh, ich sollte mich mal anmelden.
Also ich habs jetzt alles rausgefunden:
dadurch, dass man 2 Prozesse erzeugt und beide Prozesse die Pipes der anderen mitvererbt bekommen, sind diese weiterhin geöffnet.
Im Parentprozess wird aufs schließen der pipe nicht reagiert, weil der andere Prozess diese ja noch offen hat.
Jaa, wenn der Prof sagt man soll alle schließen, dann sollte man das tun xD
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum C (C89 und C99) 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.
Das klingt so, als wäre sshfs etwas für dich. Damit kannst du ein entferntes Dateisystem über ssh bei dir mounten und dann lokal arbeiten.
Falls das nicht reicht, kannst du, wenn genug Bandbreite da ist, auch X11 durch SSH forwarden und GUI-Programme dann direkt auf dem Server ausführen. Dafür muss der Server X11-Forwarding erlauben, also sich in der sshd_config (die befindet sich üblicherweise in /etc/ssh) die Zeile
X11Forwarding yes
finden, und der Client muss X11-Forwarding benutzen, es muss also in der Client-Konfiguration (~/.ssh/config für einzelne Benutzer oder /etc/ssh/sshd_config für alle, bei denen die Benutzerkonfiguration nichts anderes sagt)
ForwardX11 yes
stehen. Wahlweise kannst du statt der Client-Konfiguration auch beim Verbindungsaufbau die entsprechende Option mitgeben:
ssh -X servername
Wenn dann auf dem Server ein grafischer Dateisystembrowser installiert ist, kannst du ihn einfach ausführen, und dein lokales X11-Display wird dafür benutzt.
AirTrake schrieb:
wenn ich nur sudo schreib gehts nicht was bringt tee ?
sudo echo foo gibt mit Root-Rechten aus. Wenn du da jetzt ein > foo dranhängst, dann geschieht diese Umleitung mit Userrechten. Wenn du jetzt noch die verlinkte Tee-Manpage liest, sollte dir klar sein, was das tee bringt.
Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C (C89 und C99) 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.
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum C (C89 und C99) 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.
Weil das ursprüngliche grep aus UNIX V7 die -q-Option nicht beherrscht. :p
Aber Spaß beiseite, wenn man sich auf POSIX stützen kann, was meistens der Fall sein dürfte, ist -q natürlich hübscher. Ich hab das bloß nicht auswendig gewusst.
Der aus dem Westen ... schrieb:
Direkten Speicherzugriff gibt es nur in der System- und Treiberprogrammierung. Früher, in den Tagen von DOS und UNIX (obwohl, bei UNIX bin ich mir nicht sicher, bin mit MS-DOS aufgewachsen), da konnte ein Programm noch direkt auf die Speicherzellen im RAM zugreifen.
Virtual Memory kam in der Unix-Welt Ende der 70er Jahre unter Berkeley Unix (müsste 3BSD auf der VAX gewesen sein).
Der Rest deines (übrigens äußerst wertvollem) Beitrag trifft in der Form auch nur auf x86-Systeme richtig zu (auch wenn die beschriebenen Techniken natürlich auch anderswo Verwendung finden), das sollte man vielleicht dazu sagen.
Zur Frage des Threadstarters noch:
Unter vielen Unix-Implementierungen (unter anderem eben auch unter Linux) gibt es (wie rüdiger bereits angedeutet hat) unter /dev/mem (siehe mem(4)) eine Gerätedatei, über die man (entsprechende Rechte vorausgesetzt) die Inhalte des physikalischen Speichers auslesen und durchaus auch ändern kann, wobei letzteres natürlich recht heikel ist. Zum Rumspielen durchaus interessant, es gibt aber nur sehr wenige Klassen von Programmen, in denen diese Funktionalität tatsächlich sinnvoll verwendet werden kann.
pyhax schrieb:
Nein. Er will die Lib ja dynamisch öffnen, und nicht hinzulinken,
bist du dir da sicher?
Für mich klingt das ganze eher so als ob er den code einer Klasse in eine shared lib packen möchte. Und diese klasse samt lib in einem program zu verwenden, und zwar ohne den code der klasse nochmals übersetzen zu müssen.
seldon schrieb:
Sonst sind grep und sed deine Freunde. C würde ich hierfür nicht auspacken; damit wäre das deutlich komplizierter.
Ich glaub es geht mehr um den Lernerfolg, als darum etwas extrem praktisches zu schaffen. Ist ja eigentlich eine prima Aufgabe. Man lernt über die Linux socket-API. Man lernt ein bisschen wie HTTP aufgebaut ist. Man gewinnt natürlich Programmierpraxis.
Lolek schrieb:
und festgestellt das es noch jede Menge Lesestoff durch zuarbeiten gibt.
Es schadet auch nicht, wenn du zwischendurch ein paar andere Dinge ausprobierst. Ich meine einfachere Beispiele wären, dass du eine Textdatei öffnest und zählt wie oft welcher Buchstabe darin vorkommt oder wieviele Zeilen die Datei hat. Dabei könntest du das einmal mit der C++ ifstream-API programmieren, dann mit der C fopen-API und dann einmal mit der Unix/Linux lowlevel open-API.
seldon schrieb:
gdb ist ein guter Anfang, aber im Embedded-Bereich ist es häufig ziemlich unpraktisch, den ganzen gdb auf der Zielmaschine laufen zu lassen. Üblich ist, soweit ich das überblicke, auf der Zielmaschine einen gdbserver laufen zu lassen, der sich an einen Prozess anhängt, um dann auf der Entwicklungsmaschine den eigentlichen gdb laufen und mit diesem Server sprechen zu lassen. Auf die Art kann man dann auch ohne Probleme nemiver, kdbg, ddd oder sonstige Frontends (da hat wohl jeder sein Lieblingsviech) vorschalten, um sich die Arbeit zu erleichtern.
Ich denke, dass eine solche Umgebung durchaus für die ersten Applikationen genügen dürfte. Kernel-Debugging per JTAG soll ja hauptsächlich für die Erstellung von BSPs notwendig sein, oder ? Da bildet dann der entsprechende Daemon mit dem JTAG den GDB-Server nach und das Debuggen kann dann auch mit dem gleichen Client ablaufen, wie ich gelesen habe...
dem compiler ist an der stelle die reihenfolge egal. Sollange die syntax passt.
Ich denke das du die priorität über "pthread_setschedparam" erst nach dem erstellen des threads machen kannst denn vorher enthält zb. die save_thread variable keine gültige informationen über einen thread.
Du kannst aber beim erstellen des threads diese information auch übergeben siehe man pthread_attr_init
