Seite 1 von 1

[QT4, MSVC] *.dll's einbinden.

Verfasst: 13. Oktober 2005 10:11
von m.trix
Hello again...

Ja ich schon wieder. Bin immer noch 'neu' in Sachen Qt, und for allem .dll's. Deswegen folgende Frage:
Gibt es eine Möglichkeit, meine Applikation auf einem Rechner ohne installiertem Qt zum laufen zu bringen, ohne das ich die .dll mitgeben muss? Ich mein so eine Arte resource wie mit icons etc.. Gibt's da was?


PS:Hab diesmal nur hier danach gefragt. :)

Verfasst: 13. Oktober 2005 10:27
von Goos
Hmmm was bitte ist fuer dich ein "installiertes" QT? ;)
Ansonsten kannst die QT Libs auch statisch zu deinem Programm linken und dann auch ohne "installiertes" QT (wie du dich ausdrueckst) starten.

Goos

Verfasst: 13. Oktober 2005 10:33
von FlorianBecker
Diese Möglichkeit besteht nur, wenn du deine Anwendung statisch gg. die Qt Libs linkst. Sonst mitgeben, aber als Ressource geht das nicht, da die Lib vorher verlangt wird, bevor du anfängst das eigentliche Programm zu benutzen.

Verfasst: 13. Oktober 2005 10:40
von m.trix
Ich arbeit mit der commercial. So wie meine Kollegen auch, ich aber mit Qt 4.0.1. Zu Testzwecken. Wenn ich denen aber mein Tool schicke, wird immer nach ein paar dll's gefragt. Wenn die im Ordner der exe liegen ist das ganze kein Problem.

Meine schwammige Ausdrucksweise kommt aus purem Unwissen heraus. Bin mit dem Projekt ins kalte Wasser geschmissen worden. Was natürlich kein Vorwurf ist. Aber ich tu mich halt ein wenig schwer. Ausser ein paar popelige Konsolenprogramme hab ich bisher noch nix gemacht. Deswegen weis ich auch nicht wirklich wie mal dls statisch, dynamisch oder sonst wie verlinkt oder einbindet.

Ich hätt halt gern, dass das Tool einfach auf jedem x-belibigen Rechner läuft. Ohne das die dlls im Ordner liegen müssen.

Verfasst: 13. Oktober 2005 10:44
von FlorianBecker
Ja, schön, aber eine alternative Lösung gibt es nicht. Statisch linken und das passt. Folgende Vorgehensweise:
- Qt Libs statisch bauen
- Gegen eben die neu gebauten Libs linken, wie das mit Programmen eben üblich ist
- Fertig.

Es ist eigentlich genauso wie immer, nur, dass du eine statische Qt Version hast.

Verfasst: 13. Oktober 2005 10:54
von m.trix
Danke für die Tipps.
- Qt Libs statisch bauen
- Gegen eben die neu gebauten Libs linken, wie das mit Programmen eben üblich ist
- Fertig.
Aber: Ich hab keine Ahnung wie das geht.

Verfasst: 13. Oktober 2005 10:55
von klogg
HA! Glaubt mal nicht, ihr könnt hier einen Thread über statisches Linken machen, ohne dass ich das mitkriege! :P

Gehen tut das so:
Du lädst dir von Trolltech QT als Source runter.
(Da ist dann auch eine Hilfedatei dabei, da steht alles drin)
Jedenfalls musst du in der Konsole dann
configure -static eingeben und danach
make

Und zumindest bei mir läuft das nicht durch,
weil er mit Fehlermeldungen abbricht.

HENNING

Verfasst: 13. Oktober 2005 11:01
von FlorianBecker
Ja, dann ist das natürlich blöde. Wo genau geht es denn nicht "durch" ? Und vor allem, von welcher Version genau redest du?

Verfasst: 13. Oktober 2005 11:05
von klogg
Ich nehm QT 4.0.1 und dann wie beschrieben und dann irgendwann:
uilib\ui4.cpp: In destructor `DomLayoutDefault::~DomLayoutDefault()':
uilib\ui4.cpp:1594: internal compiler error: in rest_of_handle_final, at toplev.c:2064
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.mingw.org/bugs.shtml> for instructions.
mingw32-make[5]: *** [tmp\obj\release_static\ui4.o] Error 1
mingw32-make[5]: Leaving directory `C:/Qt/4.0.1/tools/designer/src/lib'
mingw32-make[4]: *** [release] Error 2
mingw32-make[4]: Leaving directory `C:/Qt/4.0.1/tools/designer/src/lib'
mingw32-make[3]: *** [sub-lib-make_default-ordered] Error 2
mingw32-make[3]: Leaving directory `C:/Qt/4.0.1/tools/designer/src'
mingw32-make[2]: *** [sub-src-make_default-ordered] Error 2
mingw32-make[2]: Leaving directory `C:/Qt/4.0.1/tools/designer'
mingw32-make[1]: *** [sub-designer-make_default-ordered] Error 2
mingw32-make[1]: Leaving directory `C:/Qt/4.0.1/tools'
mingw32-make: *** [sub-tools-make_default-ordered] Error 2
Ich hab's auch schon mit mehreren Snapshots probiert
und das funktioniert auch nicht. Da gibt's dann aber andere Fehler.

HENNING

Verfasst: 13. Oktober 2005 11:17
von FlorianBecker
Ja, aber dann bricht er erst beim Designer ab, also sind die Libs da. Kein Problem.

Verfasst: 13. Oktober 2005 12:24
von klogg
FlorianBecker hat geschrieben:Ja, aber dann bricht er erst beim Designer ab, also sind die Libs da. Kein Problem.
Soll das bedeuten, du kennst das Problem bei den Snapshots
und meinst jetzt, das kann man zumindest soweit erstellen,
dass man es zum kompilieren (evtl. statisch) nutzen kann?

Kann ich denn dann parallel dazu noch 4.0.1 mit Designer nutzen?

HENNING

Verfasst: 13. Oktober 2005 12:35
von FlorianBecker
Also ich mache das immer so:
Grundversion ist auch als QTDIR gesetzt.
Alternative Versionen, z.B. statisch, oder besondere builds und die verschiebe ich dann jeweils so, dass dorthin das QTDIR zeigt, wenn ich diesen Build benötige.

Es spricht also nichts dagegen das zu machen. Das Problem mit den Snaps? Ein Problem würde ich das nicht nennen, denn die arbeiten momentan noch sehr heftig an Qt, also es ist ehr pure Entwicklung und da geht schon öfters was schief.

Verfasst: 13. Oktober 2005 13:36
von macman
FlorianBecker hat geschrieben:Das Problem mit den Snaps? Ein Problem würde ich das nicht nennen, denn die arbeiten momentan noch sehr heftig an Qt, also es ist ehr pure Entwicklung und da geht schon öfters was schief.
So kann man es nennen. Momentan ist an echten Einsatz nicht zu denken, so buggy ist das. Scrollen funktioniert praktisch überhaupt nicht, Redrawfehler en masse, usw. Ich melde inzwischen nur noch die Bugs, von denen ich annehme das es auch welche sind.

Verfasst: 13. Oktober 2005 15:55
von Goos
macman hat geschrieben:Ich melde inzwischen nur noch die Bugs, von denen ich annehme das es auch welche sind.
Wie meinst das?
Kannst dich nicht entscheiden, ob es Bugs oder wichtige Features sein sollen? :D

Goos

Verfasst: 13. Oktober 2005 16:20
von macman
Beispiel: Ich habe ein QTreeWidget und setze die Headerlabel. Dann hole ich mir die QHeaderView und setze einen ToolTip, der aber nicht angezeigt wird.
Das ist ein Bug :) Tracknummer: 89245
Oder noch übler, QTreeWidget mit mehreren Spalten. Ich füge einige QTreeWidgetItems ein und gebe allen das Flag ItemIsUserCheckable für Spalte 0. Jetzt füge ich weitere Items ein, aber mit einem Item als Parent. Alles noch ok. Geb ich den Items aber zusätzlich das Flag ItemIsTriState, dann hat das Item mit den Children Checkboxen in allen Spalten.
Das ist ein Bug :)
Falls das einer mal prüfen will:

Code: Alles auswählen

#include <QtGui>

int main( int argc, char** argv )
{
    QApplication app( argc, argv );
    
    QTreeWidget* treeWidget = new QTreeWidget;
    treeWidget->setColumnCount(4);

	QTreeWidgetItem* item = NULL;
	for (int l=0; l<5; l++)
	{
		item = new QTreeWidgetItem(treeWidget);
		item->setText(0, QString::number(l));
		item->setText(1, QString::number(l));
		item->setText(2, QString::number(l));
		item->setFlags( Qt::ItemIsUserCheckable | Qt::ItemIsSelectable | Qt::ItemIsEnabled );
		item->setCheckState(0, Qt::Unchecked);
//		item->setFlags(item->flags() | Qt::ItemIsTristate );
	}

	QTreeWidgetItem* parentItem = treeWidget->topLevelItem(3);
	for (int l=0; l<5; l++)
	{
		item = new QTreeWidgetItem(parentItem);
		item->setText(0, QString::number(l));
		item->setFlags( Qt::ItemIsUserCheckable | Qt::ItemIsSelectable | Qt::ItemIsEnabled );
		item->setCheckState(0, Qt::Unchecked);
	}

	
	treeWidget->show();
    
    return app.exec();
}
Wenn ich aber die ganzen Redrawfehler sehe, das wissen die selber, das brauch ich nicht zu melden. Auch melde ich einen Fehler erst, wenn er in mehreren Versionen drin ist. Manche kommen und gehen wieder.