[RalphS]

Der einfachste Weg ist, die Chose statisch zu linken.

EXE größer. Aber dafür keine Abhängigkeiten.

[Holger_N]

Das habe ich auch schon versucht, aber das Script läuft nicht durch. Ich muss mir das nochmal genauer angucken. Erstmal bin ich ja schon froh, dass es so funktioniert, wie es funktioniert.

[RalphS]

Wow, ich krieg's sogar ohne bewußte Steuerung hin, auf der HS ordentlich Minus zu kassieren.

Zugegeben, manchmal macht es Spaß, Kontroverses zu posten und sich dann an den wachsenden Minusen zu freuen und sich dann zu fragen, tscha mmmmh, was sagt das eigentlich über die Kollegen aus, wenn die sowas abminusen?

Aber daß es für Absoluta wie Lizenzen, die man hat oder nicht hat, auf Herausstellung dieses Umstands (bisher) fast 20 Minus kassiert, na das hatte ich dann doch nicht erwartet. Gute Nacht Deutschland. Aber wenigstens hab ich was zu lachen.


Moin.

[Holger_N]

Wie funktioniert denn das dann mit dem statisch Gelinkten? Also ich meine nicht, wie ich das einrichte, dafür gibts ja Anleitungen aber wie das dann generell abläuft. Dann muß doch alles gelinkt werden und die Exe wird 800 MB groß, auch wenn für das Programm 8 MB reichen oder das Programm linkt nur das, was es braucht aber das erkennt es ja nicht, sonst könnte es ja auch ohne statische Verlinkung vorher sagen, welche DLLs es braucht, dass ich die mit einpacke.

[RalphS]

800MB? War das ein Beispiel, oder wurde das bei Dir echt so viel?

- Statisches Linken wird zur Erstellzeit (on linkage) aufgelöst.

> Im Gegensatz dazu dynamisches Linken: Hier wird einfach eine Referenz eingetragen. Funktion namens X gibt es in DLL D. Fertig. Deswegen ist dynamisches Linken auch potentiell unsicher: Habe ich eine DLL D mit einer Funktion X und ich rufe mein Programm auf, dann lädt das diese DLL. Völlig egal, wie und was und wo. Nur die DLL muß den Namen haben (hier D) und die Funktion muß drin existieren (hier X) und nichts weiter. Gibt's die DLL D ohne Funktion X, heißt es "Funktion" bzw "Einstiegspunkt" nicht gefunden. Gibts DLL und Funktion, aber die Funktion hat die falsche Signatur (bzw unpassende) gibt's einfach einen Laufzeitfehler und die Anwendung steigt aus.


> Statisches Linken ermittelt ebenso die Funktionsliste. Hier reicht es aber nicht aus, die Funktionen zu referenzieren (byref) sondern ich muß sie übergeben (byvalue). Der Linker "sollte" in der Lage sein, Bezüge zur Linkzeit aufzulösen, sprich wenn ich ne Funktion F hab und die referenziert eine andere Funktion S1 (statisch verlinkt) und die wiederum will aber eine Funktion S2 haben (ebenfalls statisch), dann merkt der Linker das und bindet beide ein.

Statische Linkarchive (.a / .lib bei VS) sind auch relativ banal. Das ist einfach Objektcode in ein durchsuchbares Archiv gepackt (mit Index). Dann, wenn man sagt "jetzt erstellen", wird aus dem eigenen Code die .o / .obj - Dateien, die man selber gebaut hat, hergenommen und aus den statischen Archiven, von denen man gesagt hat, die verlinkt werden sollen, die nicht aufgelösten Referenzen zusammengesucht und diese dann ins Ergebnis reinkopiert. Es sieht dann also hinterher so aus, als ob alle Funktionen von Dir selber geschrieben wurden. Sie stecken auch alle in der ausführbaren Datei, ohne weitere Referenzen (deswegen werden sie ja so groß).

800MB... falls das nicht grad ein Beispiel war, könntest Du schauen, wie es mit Debuginformationen in der Datei aussieht. Evtl kann man die rausstrippen. Oder Du hast versehentlich die Debugkonfiguration genommen und es wurden die statischen Debuglibs genommen. Die sind dann natürlich tatsächlich irgendwann riesig.

Wenn es 800MB oder sowas trotz allem bleiben, dann schau mal, ob Du mit UPX was bügeln kannst. Das ist ein Laufzeitkompressor für ausführbare Dateien.

[Holger_N]

Nee, das war war jetzt nur ein Beispiel mit den 800 MB. Ich habe das statische ja noch nicht hinbekommen. Ich meinte das so, wenn ich nicht statisch linke, dann suche ich mir doch die DLLs, die ich brauche und die es auf dem System normalerweise nicht gibt und packe die in den Programmordner mit rein (macht das Setup-Programm ja vorbildlich), dann habe ich am Ende ein Paket von vielleicht 8 MB. Fertig.

Wenn ich statisch linke, packt es aber nicht die DLLs ein, die es braucht, sondern packt alles was da ist in die exe und das sind ja dann erheblich mehr weil es ja keine Möglichkeit gibt, herauszukriegen, welche DLLs gebraucht werden und welche nicht, außer mit stundenlangem probieren.

UPX habe ich schon ausprobiert. Das ist ne schöne Sache, um zu verkleinern und ich werde das auch gegebenenfalls mal nutzen, ändert aber nichts am Problem. Dann wäre der Größenunterschied zwar kleiner aber trotzdem hätte ich doch hunderte DLLs in der Exe statisch verwurstet, die ich nicht brauche.

Dieser Beitrag wurde von Holger_N bearbeitet: 06. Juni 2017 - 20:55

[RalphS]

Ich glaub Du verstehst da was miß.

DLLs = Funktionsbibliotheken. Du hast also ein Buch geschrieben mit Fußnoten und einen Index hinten. Jetzt kann man in dem Index die von Dir verwendeten Bücher finden. Dazu geht man in die Bibliothek (=> die DLL) und sucht sich die benötigten Bücher dort raus. In der Bibliothek (=> der DLL) befinden sich üblicherweise sehr viel mehr Bücher (Funktionen) als die, die Du referenziert hattest.

Das wäre dynamisch.

Statische Libraries: Du hast also ein Buch geschrieben. Aber diesmal verwendest Du keine Fußnoten, sondern Du schreibst sozusagen den ersten Teil und hinten hast Du keinen Index, sondern eine Übersicht der verwendeten Fachbegriffe.

Die sind dort hinten alle fein säuberlich erklärt. Andere Bücher brauchst Du nicht mehr.

Diese Liste mit den Fachbegriffen ist aber nicht erschöpflich. Nur die Fachbegriffe sind erklärt, die auch tatsächlich verwendet wurden.


Wie dick ist jetzt das Paket mit dem Buch?

Für (a) kommt es drauf an, wie umfangreich die Bibliothek war. Da Du genötigt bist, die gesamte Bibliothek mitzuliefern, hängt der Gesamtumfang also unmittelbar vom Umfang der Bibliothek ab. Das Buch selber ist schlank. Außerdem kannst Du optional sagen, such Dir doch selber ne Kopie der Bibliothek.

Für (b) kommt es auf den Umfang der verwendeten Funktionen an. Je mehr verwendet wurden (die Du nicht selber geschrieben hattest) desto dicker wird der Anhang und desto dicker das Buch, welches nun allein im Paket liegt.


Ergo, je mehr externe Funktionen verwendet werden, desto mehr profitiert man vom dynamischen Linken. Andersherum eher vom statischen.

Und wenn Du nicht die ganze Bibliothek mitliefern willst oder kannst, dann statisch. Ist auch zuverlässiger, weil keiner Bücher aus der Bibliothek austauschen kann, wo Du's nicht weißt. Andererseits kann so Buch 2.0 verwendet werden, wo Du nur Buch 1.0 hattest, weil Buch 2.0 noch nicht fertig war.

[Holger_N]

Das mit dem Buch ist mir grad zu kompliziert, ich verstehe ja auch immer diese Waschmaschinenbeispiele nicht, die mir die Klassen erklären wollen. Deshalb kann ich da ja immernoch nichts mit anfangen. Nee ich mache mal ein reales Beispiel.



Mein Medizinplaner braucht (je nach Compiler) folgende Dateien, damit es auf einem anderen Rechner funktioniert:

Die exe selbst, logisch

und dann packe ich dazu:

Qt5Core.dll
Qt5Gui.dll
Qt5Widgets.dll

so, die sind nachvollziehbar, dann muß ich aber noch dazupacken

libgcc_s_dw_2-1.dll
libstdc++-6.dll
libwinpthread-1.dll

dann muß noch ein Ordner:

platforms

dazu, in welchem sich die:

qwindows.dll

befindet. Dann funktioniert alles, wobei man die letzten Vier nur durch Recherche und viel Probieren rauskriegt. Und je nach Umfang des Programmes kommen dann eben noch Sachen dazu. Wenn ich nun solch ein statisches Linkding bastel, dann müssen die Funktionalitäten dieser DLLs doch auch irgendwie in die Exe integriert werden. Wenn die Entwicklungsumgebung aber vorher nicht weiß, was alles reingepackt werden muß, dann muß ja alles rein, was da ist damit es funktioniert. Auch die Sachen die überhaupt nicht gebraucht werden. Denn wenn die Entwicklungsumgebung wüßte, was rein muß und was nicht, könnte die es mir ja auch bei der dynamischen Variante freundlicherweise sagen, dass ich nicht wochenlang probieren muß.


Oder ich versuche es mal so wie ich das Buchbeispiel inzwischen verstehe. Wenn ich nun aus einem Buch was ich sonst mitliefern würde, die Fachbegriffe rausschreibe und die Erklärungen für mein Buch übernehme, dann weiß ich ja, aus welchem Buch ich die abgeschrieben habe und könnte für die dynamische Version sagen »Du brauchts zusätzlich das Buch A.« Das kann die Entwicklungsumgebung im Falle der DLL aber nicht.

Dieser Beitrag wurde von Holger_N bearbeitet: 06. Juni 2017 - 22:14

[der dom]

@Holger - was RalphS meint ist - erstelle eine Instanz eines Objektes und greifst dann über die instanziierte Mimik drauf zu ist es nicht statisch.

Sprich:

Machwas tu = new Machwas();
tu.Irgendwas();

Statisch wäre hingegen:
Machwas.tu();

und das ohne ein Object explizit zu erzeugen und dann über die Instanz auf die Methoden zuzugreifen....

Männers - das ist off-off-Topic :-D

Moinsen.

@R & H - Ich weiß - setzen 6, trotzdem offtopic herrschaften :-P

Dieser Beitrag wurde von der dom bearbeitet: 06. Juni 2017 - 22:08

[Holger_N]

Ja manchmal muß man new dazuschreiben, manchmal muß auch noch ein Sternchen ran und dann muß statt eines Punktes so ein lustiger Pfeil gebastelt werden. Da probiere ich auch immer so lange bis es funktioniert. Am Besten ist, wenn es ohne new und ohne Sternchen funktioniert, dann ist der Code für mich logisch. Wenn ein new dazu muß, schreibe ich es hin, aber ich weiß nicht, was es macht.

Das ist aber wieder was ganz Anderes. Es geht ja darum, dass man beim Kompilieren eine Exe erzeugt, die alleine funktioniert, ohne DLLs mit auszuliefern.



(Das war jetzt natürlich etwas albern formuliert. Ich weiß, dass das mit Sternchen Zeiger sind und ich weiß auch ungefähr wie die funktionieren aber ich habe noch nicht rausgekriegt, wozu die gut sind.)

Dieser Beitrag wurde von Holger_N bearbeitet: 06. Juni 2017 - 22:24

[RalphS]

Mit OO und Instanzen hat das noch nix zu tun, es geht um Object Linking, entweder shared object (.so) oder statisch (ar archive, .a).

Der Linker funktioniert so, er schaut sich den Quellcode an, und alles was nicht irgendwo erklärt (definiert) ist hält er für eine externe Funktion. Die muß dann dem Linker über die beinhaltende Bibliothek mitgegeben werden, damit er weiß, wo er suchen kann bzw muß.

Am Ende hat der Linker ein Tabelle von externen Funktionen. Das sind die, die er nicht auflösen konnte.

Dynamisch schreibt er diese Tabelle in die EXE. Da steht dann sinngemäß drin:

QShowWindow(qint) | QtGui.dll
QDrawImage(qimage) | QtRender.dll

und so weiter. Damit er das kann, wird er für jede unbekannte Funktion versuchen, die in irgendeiner der übergebenen DLLs zu entdecken. Findet er den Funktionsnamen in der DLL, wird beides in die Tabelle in der Exe geschrieben.

Wenn man jetzt die Exe ausführt, versucht er die Funktion zur Laufzeit zu holen über die zugeordnete DLL. Die muß dazu vorhanden sein.

---

Statisch hat der Linker dieselbe Tabelle. Aber nun schreibt er die nicht in die EXE rein, sondern er arbeitet die Tabelle höchstselber ab. Die Bibliotheken sind diesmal keine DLLs, sondern .LIBs oder .As . Programme können damit nix anfangen: Das sind reine Link Libraries.

Der Linker geht also da rein und sucht auch wieder die Funktionen zu den referenzierten Namen. Das geht diesmal über den Index in der Link Library. Hat er einen passenden Eintrag gefunden, wird der zugehörige Objektcode, der die Funktion beinhaltet, aus der Bibliothek rauskopiert und in die EXE eingefügt. Das sind natürlich mehr Daten als ein simpler Tabelleneintrag.


Sprich, statisch hast Du nur das Benötigte in der EXE. Dynamisch brauchst Du die gesamte DLL - normal läßt die sich nicht in Teile zerlegen, es sein denn natürlich, Du baust selber Funktionsbibliotheken.


Damit das klappt, muß man statische Link Libraries auch *haben*. Wenn es nichts gibt, was mir den Objektcode definiert, dann kann ich ihn auch nicht in meine EXE reintun.


Für Qt-Anwendungen ist das auch eigentlich recht oft, daß man das so macht. Eben wegen der sonst umfänglichen Abhängigkeiten.

Falls Du noch nicht hast, es gibt für Qt ein SDK was man runterladen und nehmen kann. Da steckt alles drin. Ist aber auch recht groß, wenn man alles mitnehmen will. Du müßtest bei der Auswahl nach den statischen Paketen und, wenn ich das richtig lese, nach der MinGW-Architektur schauen (VS wird dir nicht viel nützen, wenn Du MinGW verwendest).

Außerdem mußt Du, wenn Du nicht schon hast, eine statisch verwendbare C/C++-Laufzeit beschaffen. Eigentlich sollte die Teil der gcc-Suite sein, aber keine Ahnung was da heutzutage alles wo hin ausgegliedert wurde.

[Holger_N]

Man muß da, laut Tutorial nur irgendwas runterladen (Link war dazu) in drei oder vier Dateien ein paar Anpassungen machen (Da steht dann aber nur »Ändern Sie blub in blab« aber leider nicht in welcher Datei oder »A und B muß gegebenenfalls angepasst werden« aber es steht nicht wann der Fall gegeben ist und wie die Anpassungen aussehen muß) und am Ende muß man ein Perlscript aufrufen. Das soll dann ein paar Stunden dauern und dann ist die statische Version fertig.

Also im Prinzip will ich das gar nicht so unbedingt mit dem statischen Linken. Sieht ja auch viel professioneller aus, wenn im Programme-Ordner nach der Installation ein bißchen was drin ist. Mir würde ja reichen, wenn mir die Umgebung sagt, welche DLL ich mitgeben muß. Wenn die die Eintäge in diese Linkliste macht, müßte das doch bekannt sein.

Ansonsten habe ich VS (für 64bit Anwendungen) und MinGW (für 32bit Anwendungen).

Dieser Beitrag wurde von Holger_N bearbeitet: 06. Juni 2017 - 22:47

[RalphS]

Klingt seltsam. Aber, gut, wer weiß wie die das bei Qt jetzt handhaben. Mit syncqt seh ich eh nicht durch, was das soll. Insbesondere, weil es nicht funktioniert, außer vielleicht unter *nix & co. :/

Ansonsten hast Du zwar nicht ganz unrecht, aber am Ende des Tages ist die statische Lösung... nicht immer, aber oft die professionellere. Sie ist robuster und sie ist weniger malware-anfällig, weil Funktionen nicht zur Laufzeit eingebunden werden.

Wie Du's am Ende vertreibst ist ja egal. Wichtig ist nur, daß es richtig funktioniert, und da nimmt sich das alles nix.

[Holger_N]

Das ist auch alles nur so halb erlaubt. Also es steht ja nirgends genau. Auf der Qt-Seite ist alles soweit nur in Englisch und juristische Texte versteht man ja schon in seiner Muttersprache nur halb, da nutzt einem eine Übersetzung vom Englischen ja dann nichts. Die ist dann ja nochmal doppelt so ungenau. Jedenfalls die meisten Übereinstimmungen gab es bei der Ausführung, dass die statische Variante eigentlich der kommerziellen Version vorbehalten ist, inzwischen wird das auch bei der Free-version geduldet, man muß dann aber zusätzlich den Quellcode offenlegen. Wobei das aber bei Programmen, die man kostenlos verteilt insgesamt nochmal sehr entspannt gesehen wird.

[RalphS]

Aha. Na gut, mit dem Lizenzmodell von Qt hab ich mich noch nie auseinandersetzen müssen, gottseidank. War nur einmal in deren Foren unterwegs, als es noch Nokia war. Und die haben sich dort alles angeeignet per AGB: "Was Du hier schreibst, geht in unseren Besitz über, insbesondere, falls Geheimnisse oder Algorithmen zur Problemlösung gepostet werden sollten. Das ist nicht einklagbar." oder so ähnlich.

Hab ich denen den Vogel gezeigt.