Ich habe unter Ubuntu-Linux ein kleines Testprogramm mit FLTK/Fluid geschrieben, womit ich dynamisches/statisches linken teste. Dynamisch gelinkt ist es 21 kByte, statisch gelinkt 580,7 kByte groß. Statisch dazu gelinkt wird nur die FLTK-Library. Beide Programme funktionieren auf meinem PC gleich (Bild OutWin.png die anderen Bilder zeigen die Dateigrößen).
Wenn ich mir in der Konsole mit "file QtTest" dessen Eigenschaften ansehe steht dort beide male "dynamically linked", was mich etwas verunsichert.
QtTest: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=ab966515cfaa015f744d7423b747e04cff3242fe, for GNU/Linux 3.2.0, with debug_info, not stripped
Wenn ich in der Konsole mit "ldd QtTest" der statisch gelinkten Version die Liste der dynamisch gelinkten Librarys für das Programm ansehe, finde ich dort kein FLTK. Dies bedeutet zusammen mit der Dateigröße doch, daß FLTK statisch gelinkt ist. In der dynamisch gelinkten Version ist FLTK mit aufgeführt.
Meine Frage: Da ich auf allen meinen Rechnern FLTK installiert habe, wie kann ich sicher sein dass das Programm auf Rechnern ohne installiertes FLTK läuft?
Habe eine statisch und eine dynamisch gelinkte Version des Programms erstellt und gespeichert. Danach FLTK deinstalliert und jede Version mal gestartet. Die dynamische Version läuft nicht mehr, die statische Version funktioniert.
Da der PC ein normales Ubuntu Entwicklungssystem, ohne Besonderheiten, ist sollte das Programm auf den meisten Linux-PC's laufen. Und falls nicht kann man mit "ldd" nachsehen was fehlt.
Jetzt hoffe ich nur, dass ich FLTK wieder installieren kann. Bei www.fltk.org ist heute der Wurm drin und sie sind nicht erreichbar.
Habe eine statisch und eine dynamisch gelinkte Version des Programms
erstellt und gespeichert. Danach FLTK deinstalliert und jede Version mal
gestartet. Die dynamische Version läuft nicht mehr, die statische
Version funktioniert.
Umbenennen haette gereicht.
Da der PC ein normales Ubuntu Entwicklungssystem, ohne Besonderheiten,
ist sollte das Programm auf den meisten Linux-PC's laufen. Und falls
nicht kann man mit "ldd" nachsehen was fehlt.
Das ist nur das Prinzip Hoffnung. Oder hast du geprueft welche
externen Referenzen noch von FLTK angezogen werden? Die koennen ja
durchaus in weiteren dynamisch gelinkten Libs liegen...
Jetzt hoffe ich nur, dass ich FLTK wieder installieren kann. Bei
www.fltk.org ist heute der Wurm drin und sie sind nicht erreichbar.
Normalerweise installiert man doch Pakete für seine Distribution über den Paketmanager seiner Distribution. Bei Dir also deb Pakete aus Ubuntu. Brauchst Du die aller neueste Version von fltk?
Jetzt hoffe ich nur, dass ich FLTK wieder installieren kann. Bei
www.fltk.org ist heute der Wurm drin und sie sind nicht erreichbar.
Wenn das Programm nachher möglichst problemlos auf andere Linux-Installationen übertragbar sein soll, wär libfltk-dev / libfltk1.3-dev aus den Paketquellen vmtl. besser.
Verhindert Probleme mit:
Motopick schrieb im Beitrag #7728523:
externen Referenzen noch von FLTK angezogen
Und du könntest dynamisch linken, und das dann einfach in ein passendes .deb verpacken, was die Abhängigkeiten reinzieht.
Normalerweise ist das ganz einfach, wenn man alles statisch linken will. Man macht einfach "gcc -s" statt "gcc", fertig. Solange man die Libs mit -lirgendnelib angegeben hat, und nicht mit libirgendnelib.so oder libirgendnelib.a, nimmt es dann jenachdem ob man -s angegeben hat oder nicht die .a oder die .so, und damit geht dann alles out of the box.
Dann kann man noch Optimierungen einschalten (-Os -Wl,--gc-sections -ffunction-sections -fdata-sections), dann ist es oft auch gar nicht mehr allzu gross.
Da wurden ja noch einige Tips gegeben, danke euch - werde ich mir ansehen.
Da FLTK 1.3.8 nun schon weg war, habe ich die Version 1.4 ausprobiert. Dort ist das Problem genau umgekehrt, es wird immer die statische Bibliothek gelinkt. Da hat so ein einfaches Programm schnell eine Größe von 1MByte. Bin wieder zurück auf 1.3.8.
Ist ja nicht für ein Projekt, sondern zum lernen und ausprobieren.
Normalerweise ist das ganz einfach, wenn man alles statisch linken will.
Man macht einfach "gcc -s" statt "gcc", fertig.
Maja, nicht ganz. Man muss schon auch von sämtlichen verwendeten Libs eine statische Version installiert haben. Und in manchen Fällen, wie es z.B. oft bei openssl gemacht wird, werden dynamische Bibliotheken auch zur Laufzeit per dlopen() nachgeladen.
Ich benutze FLTK schon seit einigen Jahren. Aber der Anfang war sowohl bei Debian als auch bei Ubuntu etwas holperig. Das lag daran, dass beide Distris gegen libfltk.so linken wollen oder aber zu alt sind.
Ich installiere FLTK seit dem immer aus dem Quelltext von der Projektseite. Da wird dann normalerweise der FLTK-Anteil immer statisch eingebunden, die Systembibliotheken jedoch dynamisch. Auf der Projektseite hatte ich damals ein Muster für ein entsprechendes Makefile gefunden.
Das funktionierte bisher immer recht gut. Ich hatte meine Programme bisher immer auf Ubuntu Systemen entwickelt. Einmal hatte ich zu einem Linux-Treffen einen USB-Stick vorbereitet und durfte erstaunt feststellen, dass mein Programm sogar auf einem WeTab lief. Ein anderes Programm lief später, ohne Installation, auch auf Arch Linux. Ich vermute, das dass das gewünschte Verhalten ist.
Ich kann die Installation aus dem Quelltext nur empfehlen, da man da immer aktuell ist und zudem auch viele Beispielprogramme bekommt, aus denen der Sinn einiger Methoden erst ersichtlich wird. Und da ich auch schon mal an einem BugFix mitgearbeitet hatte, kommt für mich sowiso keine andere Variante mehr in Frage.
Gerade eben habe ich FLTK mal kurz ausprobiert, weil ich es noch nicht kannte.
In Ubuntu konnte ich es einfach via Synaptic ohne weiteren Aufwand installieren.
Die Hauptschwierigkeit das "Hello World" ans Laufen zu bringen war statt einfach "gcc hello.cxx" fltk-config zu verwenden:
Tja, heutzutage ist ja "ChatGPT", das ich die letzte halbe Stunde mal verwendet habe.
Man kann sich darüber streiten, ob es das wirklich bringt. Im Anhang aber mal ein dynamischer Graph, der mit 100ms Sekunden update läuft.
Zu compilieren mit
fltk-config --compile graphDynamical.cxx
Was jetzt fehlt, ist das Empfangen von Daten über die serielle Schnittstelle.
Ein weiteres Problem ist die Anbindung der seriellen Schnittstelle. Fast alle PC-Guis scheinen ein Problem damit zu haben.
Da ist wohl was dran. Die serielle Schnittstelle brauchte ich bisher nicht, aber dafür das Netzwerk Interface. Bisher hatte ich nur ein Beispiel dafür gefunden und dafür sollte ich boost::asio installieren. Da sollte auch die serielle Schnittstelle enthalten sein. Aber boost scheint es nur komplett zu geben.
Daher habe ich mich dann direkt mit den Linux Systemfunktionen zergnügt, obwohl mir viele davon abgeraten hatten. War sehr lehrreich.
P.s. Mein Eindruck ist, dass allgemein davon ausgegangen wird, man könne nur das verwenden, was FLTK direkt anbietet. Aber man kann alles verwenden, was das System hergibt. Man muss nur Makefile entsprechend einrichten.
Im Bild ein Beispiel eines Linienschreibers für das LIDL PDM300-Multimeter. Es basiert auf dem Beispiel "NTSC Waveform Monitor Sim" von "Erco's FLTK Cheat Page" (https://www.seriss.com/people/erco/fltk/).
Es erhält seine Daten vom Multimeter, mit 3 Messungen je Sekunde, über einen USB/Seriell-Wandler. Benutzt werden für die Übertragung keine FLTK-Methoden, sondern die Funktionen des Betriebssystems.
Leider fehlt mir im Moment die Zeit das Programm fertig zu stellen, da ich mit einem anderen Projekt beschäftigt bin.
Beispiel dafür gefunden und dafür sollte ich boost::asio installieren.
Da sollte auch die serielle Schnittstelle enthalten sein. Aber boost
scheint es nur komplett zu geben.
Das habe ich auch schon versucht zu compilieren. Da scheint aber auch "fltk-config --compile " zu versagen und man muss es wahrscheinlich irgendwie anpassen.
Daher habe ich mich dann direkt mit den Linux Systemfunktionen zergnügt,
obwohl mir viele davon abgeraten hatten. War sehr lehrreich.
Hast Du dafür ein kurzes Codebeispiel. Wäre super, vielleicht kann man es einfach anpassen.
Ich weis jetzt nicht wofür du ein Codebeispiel haben willst. Der Netzwerkclient hat ca 1700 Zeilen. Ich könnte zwar die Methode send_request() raus kopieren, aber dann fehlen viele Informationen.
Ich fange mal mit dem Makefile aus meinem aktuellen Projekt an. Da kann man dann sehen, wie man auch so Dinge wie die clib2 einbinden kann (ca. 40 Zeilen habe ich raus gekürzt).
Die Make Datei habe ich mir im Laufe der Jahre aus verschiedenen Beispielen zusammengebastelt. Da sind auch reine C-Module dabei, deshalb zwei Compiler. Und die Debug Info wird bei
1
install -s
enfernt.
p.s. ich vergaß zu erwähnen, wo bei mir libfltk liegt:
Ich habe dir das wesentliche aus dem PDM300-Programm zusammen kopiert.
In "Schnittstelle suchen und konfigurieren" wird die durch ihren Namen angegebene Schnittstelle gesucht und mit den aufgeführten Parametern konfiguriert. Default ist ttyACM0 eingestellt, es könnte auch ttyUSB0 oder tty0 oder etwas anderes sein. Welche Schnittstelle du brauchst, musst du für dein System nachsehen und der Initialisierung in "strSio" übergeben.
Da das PDM300 nur sendet ist nur eine Methode "ReadTelex" vorhanden, in der mit der Funktion "iNum = read(SPort, &cDaten[1], 9);" ein Telegramm vom Multimeter empfangen wird. Zum senden wäre es die Funktion "write".
Es hilft sich zu erinnern, dass unter Linux alles eine Datei ist. Auch die Schnittstellen werden behandelt wie eine Datei. Sich mit den Grundlagen der seriellen Schnittstelle vertraut machen, hilft die Einzelheiten zu verstehen.
Das Beispiel ist kein Programm zum kompilieren, sondern eine zusammenkopierte Reihe an Codestücken die du, an den jeweils richtigen Stellen, anpassen und in dein Programm einbauen kannst. Die Beispiele zeigen nur den Umgang mit der seriellen Schnittstelle.
Echten Quellcode für Programme kann man in diesem Forum leider nicht veröffentlichen. Wenn man keine end- und fruchtlosen Diskussionen um Kaisers Bart haben möchte, darf man keinen Schaltplan, kein Platinenlayout und keinen Quellcode zeigen.
Echten Quellcode für Programme kann man in diesem Forum leider nicht
veröffentlichen. Wenn man keine end- und fruchtlosen Diskussionen um
Kaisers Bart haben möchte, darf man keinen Schaltplan, kein
Platinenlayout und keinen Quellcode zeigen.
Da hast Du recht, das Forum ist oft etwas nörgelig. Es gibt ja keinen perfekten Quellcode, deshalb kann man auch immer meckern.
Ich versuche immer trotzdem die Beispiele vollständig und kompilierbar zu halten ( inclusive Compilier-Command Line) wie im Beispiel oben:
Ich habe dir eine Mail, mit dem vollständigen Quellcode des Multimeterprograms, geschrieben. Ohne die Hardware startet es nicht, aber es zeigt dir die nötigen Schritte im Zusammenhang. Es ist ein FLTK Programm.
Echten Quellcode für Programme kann man in diesem Forum leider nicht
veröffentlichen. Wenn man keine end- und fruchtlosen Diskussionen um
Kaisers Bart haben möchte, darf man keinen Schaltplan, kein
Platinenlayout und keinen Quellcode zeigen.
Das ist natürlich Quatsch, sofern man keinen besonders abnormen Programmierstil hat, oder sehr grobe Schnitzer in seinen Code eingebaut hat.
Das ist natürlich Quatsch, sofern man keinen besonders abnormen Programmierstil hat, ...
Hier habe ich so etwas noch nicht erlebt, aber ein anderen Foren schon. Der eine sagt, man soll lange und aussagekräftige Namen verwenden. Gleichzeitig soll die Zeilenlänge 80 Zeichen nicht überschreiten.
Wieder andere verlangen das die geschweiften Klammern immer eine eigen Zeile belegen sollen. Ich finde das Quatsch, weil dadurch der Lesefluss unterbrochen wird (Bildschirme sind dafür nicht hoch genug). Oft wird man auch dafür kritisiert, dass man bestimmte Befehle oder Methoden verwendet oder nicht verwendet.
Bei ubuntuusers.de wurde ich mal z.B. nur dafür runtergemacht, weil ich eine Funktion selber programmieren wollte, die in einer Lib bereits vorhanden war (das Rad neu erfinden u.s.w.). Aber wie soll man dann Programmieren lernen, wenn man sich nicht an praktischen Problemen ausprobiert?
Vielen Dank dafür. Nach einigen Mühen konnte ich das Programm kompilieren.
Ich habe leider kein "Multimeter PDM-300-C2", deshalb habe ich es mit einem Arduino simuliert.
Der Arduino kann damit als vermutlich etwas ungenauerer Ersatz der Spannungsmessung des Multimeters benutzt werden:
Da das veröffentlichen von Quellcode hier im Forum zu nichts führt, halte ich mich damit sehr zurück. Das bedeutet aber nicht, dass die benötigten Funktionen der seriellen Schnittstelle ein Geheimnis sind. In diesem Beitrag:
OutWin.png
(3,1 KB)
DynamicLink.png
(7,9 KB)
StaticLink.png
(8,1 KB)
