qtforum.de

Was muss man beachten damit alles ordentlich funktioniert? Sollte man die Binaries oder lieber die Sourcen verteilen? Was macht man mit Qt dll selbst? Gibt es Kompatibilitätsprobleme bei verschiedenen Linux- distributionen?

Thx.

Auf Nummer sicher gehste, wenn du die quellen weitergibst. Denn nicht alle Linux Versionen haben immer die gleiche Version von Qt an Board. Du könntest es natürlich auch alles statisch linken, aber das macht die Progs extem dick.

PS: Unter Linux gibt es keine dll's

PS: Unter Linux gibt es keine dll's

He? Dlls (Dynamic Link Library) gibt es unter jedem Betriebsystem

Denn nicht alle Linux Versionen haben immer die gleiche Version von Qt an Board

Das würde aber heißen, dass ich Qt Sourcen mitgeben muss. Aber das ist doch nicht wirklich schön...


[/quote]

Nee nicht den gazen Qt Quellcode:( Nur den von deiner Anwendung.

Beinahe jede Distribution benötigt ein eigenes Paket. Oder du baust auf einem Red Hat System binare Pakete, die laufen dann auf jeder Distribution.

Besonders verteillen!? Naja, bin gehört nach bin, lib gehört nach lib usw....

Wenn du von Unix keinen Plan hast, dann kannst du dir das so vorstellen:
c:\win\system32 = /lib
c:\programme\XXX = /bin

Zumindest in groben Zügen.

[quote]Oder du baust auf einem Red Hat System binare Pakete, die laufen dann auf jeder Distribution[/quote]

Ja das ist für mich die Frage, wo soll man alles kompilieren, damit es überall läuft. Red Hat hab ich leider nich. hab nur Suse....

Ja, aber dann kannst du es schon vergessen, musst dir die letzte Red Hat Version besorgen, denn nur die hat den passenden Compiler mit passenden Paketen.

Kannst mal versuchen., was von Fedora 4 auf Suse laufen zu lassen.
Das geht meisten schief. Denn der gcc4 mag den 3'er nicht und ungekhert:(

Ja, deshalb ja das Red Hat, das kann eben genau diese Dinge mit dem gcc machen. Eine Anwendung unter Red Hat gebaut geht auf jedem Linux. Ein Referenzprojekt ist FireFox, die haben für Linux nur ein Paket, eben mit Red Hat gebaut.

Das Problem an der Sache ist nur, dass nicht alles kompiliert werden kann, wie z.B. cairo, also gibt es derweil noch kein SVG für Linux in der stable Version, aber bei Windows und MAC schon.
Es muss eben immer auf einige Dinge verzichtet werden mit diesem Prinzip.

NoMachine hat es genial gemacht, aber es ist halt aufwendig. Für jede Distri ein Paket und ein static Paket, oder auch Opera. Das ist der bessere Weg, auch weil die Benutzer das Paket für Ihre Distri installieren und wissen wie das geht.

Die Pakete für alle Distributionen und Versionen selbst zu bauen kann seeeeeeeeeehr aufwändig sein. Ich halte es bei Kalva so, dass ich das auf meiner SuSE 9.3 erstellte Binärpaket (RPM), das Sourcepaket (SRPM), das Specfile nochmal extra und die Sourcen als Tarball veröffentliche.

Mit dem SRPM kann schon mal jeder, der eine andere SuSE-Version hat, und die Manpage von rpmbuild lesen kann, recht einfach ein passendes Binärpaket erstellen. Dazu reicht i.d.R. schon ein rpmbuild --rebuild foo.srpm.

Mit Hilfe von Sourcetarball und Spec ist es relativ leicht, ein Binärpaket für beliebige andere Distribution zu erstellen.

Wenn das Programm gpl't ist, ist das Erstellen eines Binärpakets für die eigene Distribution eine wunderbare Gelegenheit für versierte Anwender etwas zurückzugeben. Das funktioniert bei vielen Projekten eigentlich ganz gut. Kalva hat allerdings wohl noch nicht die kritische Masse erreicht, mir hat jedenfalls bisher niemand z.B. ein Mandriva- oder Fedora-Paket angeboten, für solche Angebote wäre ich dankbar und würde sie auf der Projekthomepage verlinken.

Ich benutzte einfach SRPM's oder tgz's die kann man denn auf dem zielsystem sauber mit rpbbuild -bb bzw. rpmbuild -tb überstzten und installieren.

Kannste dich ja bei Fedora extras als weralter für' Kalva RPM eintragen lassen. Dann buste aber auch für die ganzen updates sorgen.

Ja, aber genau darum geht es NICHT. Anwendung ohne Source für alle Linux Systeme verfügbar machen. Wenn ich den Source habe ist das was ganz anderes. Dann ist das nämlich egal, dann gibts den Source und ein Paket von dem Maintainer meistens.

FlorianBecker hat geschrieben:Ja, aber genau darum geht es NICHT. Anwendung ohne Source für alle Linux Systeme verfügbar machen.

Dann führt wohl kein Weg um den Rechnerpark herum (ggf. auch virtuell, sprich vmware, virtual pc, später wohl auch xen) und um entsprechend viel Zeit, weil Du viele Pakete bauen musst. Oder Du hast einen Kreis vertrauenswürdiger Anwender, die Dir die Pakete für ihre jew. Distri erstellen (wenigstens die brauchen dann aber die Sourcen).

Oder Du musst alle Abhängigkeiten durch statisch gelinkte und mit ausgelieferte Bibliotheken befriedigen, was das Paket mächtig aufblasen wird. Aber nur so lässt sich das Funktionieren auf möglichst vielen Distributionen mit nur einem Binärpaket sichern.

Je nach Art der Abhängigkeiten lassen sich evtl. noch ein par Dinge kapseln. Dann lieferst Du eine dynamische Bibliothek im Sourcecode aus, die bei der Installation auf dem Zielsystem übersetzt wird (wie bei Treiberpaketen, z.B. für ATIs Grafikkarten).

Ja, oder wie bereits oben erwähnt du holst dir Red Hat. Denn genauso macht es FireFox. Und die bringen nur eine Linux Version pro Release. Die Pakete machen die Distributionen.

Lepsai, nimm dir das Red Hat oder baue die Qt Lib im SuSE ohne xrender und frag micht jetzt nicht Support, basierend auf SuSE 8.1.

Dann baust du mit dieser Qt Version deine Anwendung und kannst die Binar rausgeben. Wenn du die als i386 baust, kann Sie jeder der einen PC mit Linux hat verwenden.

Bloß ich kenne das. Wenn jmd. kein Distripaket für seine Distri hat mekert der Anwender oder er benutzt es gleich gar nicht, oder es kommen tausende von Rückfragen.

Achja und bei Devel Libs musst du unter 64 Bit umbedingt -fpic bei gcc übergeben, damit es als shared object verlinkt werden kann.

FlorianBecker hat geschrieben:Ja, oder wie bereits oben erwähnt du holst dir Red Hat.

Mit anderen Worten Dir reicht der amerikanische Markt. Wer was anderes verwendet, hat eben Pech:-[

Es kommt ganz auf die Art der Abhängigkeiten an. Es gibt (selten) Pakete, die auf JEDER rpm-basierten Distribution laufen. Es gibt aber auch (häufiger) Pakete, die nur auf Red-Hat basierten Distributionen funktionieren und anders Systeme in den Abgrund reissen. Insbesondere sind sich Distributoren bei der Frage uneins wo denn nun QTDIR und KDEDIRS etc. hinzeigen. Besonders übel wirds, wenn eine Distribution eine andere glibc einsetzt. Das kann gewaltig schief gehen.