QT-Programm portieren

Verschiedenes zu Qt
Antworten
Bluffix
Beiträge: 14
Registriert: 2. Februar 2008 11:30

QT-Programm portieren

Beitrag von Bluffix »

Hallo,

ich möchte mein QT-Programm auf beliebigen anderen PCs ausführen und wollte fragen, was ich da mitgeben muss, also außer der exe-Datei (möglicherweise Dlls, ...) . Kann ich die dann alle in einen Ordner kopieren und auf (fast) jeder Plattform ausführen ? Oder erwarte ich da zu viel ^^ ?
PeterLustig
Beiträge: 386
Registriert: 21. November 2007 20:07

Beitrag von PeterLustig »

Dein Quellcode muss auf dem jeweiligen OS kompiliert werden.
Bluffix
Beiträge: 14
Registriert: 2. Februar 2008 11:30

Beitrag von Bluffix »

was ? echt ? Geht das nicht anders ? Dann kann ich ja meine Programme mit niemandem teilen ^^ . Warum ist das so ?
qtNiko
Beiträge: 216
Registriert: 6. April 2007 21:26
Wohnort: München

Beitrag von qtNiko »

Wenn das Prog unter Linux compiliert wurde, dann läuft es unter Linux (gleiche Version) auf allen anderen PC's, dito für Windows.
Allerdings müssen die Qt-Bibliotheken statisch gelinkt sein. Sonst braucht jeder Anwender die Qt-Bibliotheken.
Gruß von qtNiko

Core i5 760, GT 240, Suse Linux11.3, Eclipse-CDT-Helios, QT4.4, QT-Integration
dontinelli
Beiträge: 146
Registriert: 22. September 2006 20:53

Beitrag von dontinelli »

Je nachdem kannst du auch mit einem Crosscompiler arbeiten, habe aber selber noch keine Erfahrung damit. Am besten installierst du dir VirtualMachine o.ä., dann kannst du für alle Plattformen kompilieren.
Deever
Beiträge: 90
Registriert: 9. Mai 2007 18:20

Beitrag von Deever »

Bluffix hat geschrieben:Dann kann ich ja meine Programme mit niemandem teilen ^^ .
Oder du arbeitest mit PyQt. Dann brauchst du nur noch Qt und Python überall zu installieren und das Kompilieren auf jeder Plattform entfällt (bzw. wird implizit durchgeführt).
Warum ist das so ?
Weil das so ist.

Gruß,
/dev

PS: Du plenkst, warum?
RHBaum
Beiträge: 1436
Registriert: 17. Juni 2005 09:58

Beitrag von RHBaum »

Warum ist das so ?
Weil z.b das windows executable format ganz anders aufgebaut ist wie z.b. elf oder a.out binaries in linux .
Und selbst wenn das gleich waer, haben die unterschiedlichen BS immer noch ne unterscheidliche speicherverwaltung, unterschiedliche API funktionen, die sie ihren programmen zur verfuegung stellen, unterschiedliche libs fuer erweiterungen, unterschiedliches handling das Filesystems .... und noch vieles mehr.

Richtig plattform unabhaengig koennen also nur dinge sein, wo eine zwischenschicht(Interpreter) zwischen progg/code und BS ist.
Das ist bei bei reinen scriptsprachen der Fall ... und java ist son zwischending, mit vorcompilierten code der ne runtime braucht.

Alles was direkt in vom BS ausfuehrbare binaries compiliert wird, ist nimmer plattformunahaengig, weil die "besonderheiten" statisch reincompiliert wurden. das dynamsich zu machen waer unmoeglich, allein wegen den unterschiedlichen aufbau den die dinger haben muessten. das abstrahieren der BS funktionen etc auf nen gleichen nenner wuerde die sache auch quaelend langsam machen .... willkommen in der java welt :-)

Also plattformunabhaengigkeit bei compilierten programmen nur auf quellcodeebene möglich.

Ciao ...
Bluffix
Beiträge: 14
Registriert: 2. Februar 2008 11:30

Beitrag von Bluffix »

Ok, ich hatte es anders verstanden. Es müsste also unter allen Windows-rechnern schon compiliert laufen. Das ganze auf z.B. Linux zu portieren ist mir eigentlich gar nicht so wichtig.
Allerdings müssen die Qt-Bibliotheken statisch gelinkt sein. Sonst braucht jeder Anwender die Qt-Bibliotheken.
Ich dachte, bei Bibliotheken wird der entsprechend benutzte Teil in meine Exe includiert, wieso brauche ich dann noch die Bibliotheken ? Was genau muss ich dann meinem "Programmpaket" mitgeben (außer der exe-datei), damit es funktioniert ?
RHBaum
Beiträge: 1436
Registriert: 17. Juni 2005 09:58

Beitrag von RHBaum »

Statische Biblothek:
Die biblothek liegt als fertig compilierter Code vor (lib). Der linker pappt das einfach an die exe dran, ok, loest noch bissi paar symbole auf und verlinkt die (deshalb heisst der linker) ... Die bib ist nun teil des binaries und wird beim starten der exe mit geladen.

dynamische Lib:
liegt binaer compiliert auch vor, allerdings schon in einem ner exe aehnlichen Aufbau (dll). Symbole innerhalb sind alle verlinkt, die "exportierten" funktionen sind an definierter stelle beschrieben.
Dein program selber hat mit der dll beim compilieren und linken erst mal gar nix zu tun.
Laeuft es aber, und benoetigt funktionalitaet aus der Lib, sagt es das dem BS, das zieht die dll an, der code teil wird in den speicher deiner Exe eingeblendet, und per getProcAdress bekommst pointer auf die benoetigten funktionen (sofern die auch exportiert werden von der dll).
d.h. alle verlinkungen zu der dll werden erst zu laufzeit aufgeloest.

Meist wird ne Mischform unter windwos verwendet. Es wird beim erstellen der dll auch ne importlib in form einer statischen lib mitgeneriert, die linkst du auch statisch zu, die uebernimmt dir einfach das anziehen der dll, und holen der funktionspointer

So machts auch die QT, wenn die dynamsich linkt.
du links eine qt4core.lib , qt4gui.lib zu deinem programm, je nach verwendeten modulen. gibt noch paar mehr, qt4xml, qt4network ....
die ziehen die entsprechenden dlls zu an ... qt4core.dll, qt4gui.dll

Damit die dlls gefunden werden, sucht (loadlibrary ohne pfadangabe, fest in der lib eincompiliert, kannst alse ned aendern) an 3 stellen ... verzeichniss der .exe, windows systemverzeichnisse (windows, system32, system ... ) und alles was in der Pathvariable (PATH=....) steht.

Um versionskonflikte etc zu vermeiden, sollt man die dinger immer neben die exe legen ....

Ciao ...
PeterLustig
Beiträge: 386
Registriert: 21. November 2007 20:07

Beitrag von PeterLustig »

Kleine Korrektur:
Nicht Verzeichnis der .exe, sondern das aktuelle Arbeitsverzeichnis. Zumindest habe ich es so in Erinnerung. Oo
Antworten