qtforum.de

Habe qt46 installiert: einmal unter OpenSuSE 11.2 und dann nochmals unter Windows XP, welches auf dem gleichen Rechner in einer Sun VirtualBox VM läuft.

qtCreator gefällt mir gut, daher ist auch auf beiden Systemen die Version 1.3.1 installiert.

Wollte eben mal sehen, wie es mit dem Portieren auf eine andere Plattform aussieht, und holte mir einfach das "Mandelbrot"-Beilspiel.

Unter Linux übersetzt: keinerlei Probleme, alles funktioniert (bis auf die Tatsache, dass es beide CPU-Kerne auf 100% Auslastung bringt).

Unter Windows übersetzt: läuft, aber nur, wenn ich die Applikation im Creator mit dem Klick auf "Ausführen" starte. Wenn ich jedoch die "Mandelbrot.exe", die sich im "release"-Verzeichnis befindet ausführe, kommt folgende Meldung:

"Der Prozedurpunkt "??1QVariant@@QAE@XZ" wurde in der DLL "QtCore4.dll" nicht gefunden."

Was um alles in der Welt soll hier falsch sein?

Es wird eine falsche QtCore4.dll verwendet. Siehe auch Foren-Suche.

Die Suche nach "QtCore4.dll" ergibt 717 Treffer. Schon auf den ersten zwei Seiten, die ich durchgelesen habe, zeichnete sich ab, dass es mit dieser DLL häufig Probleme gibt, und die Threads enden ohne Lösung.

Wie kann es denn sein, dass "eine falsche QtCore4.dll verwendet wird"?

Daran sind offensichtlich schon mehrere Zeitgenossen verzweifelt.

Wenn PATH falsch ist wird die falsche DLL verwendet.

http://qtforum.de/forum/viewtopic.php?t ... tcore4+dll
http://qtforum.de/forum/viewtopic.php?t ... tcore4+dll

Erste Seite ...

Moin!

Ich hatte diesen Fehler auch schon einmal. Die Ursache war dabei eine Software, die ihre eigenen Qt-DLLs mitbrachte.
Dummerweise war das Verzeichnis dieser Software in der PATH-Variablen vor dem Qt-Verzeichnis, deshalb wurde die falsche DLL "gezogen".

Jetzt stehen die Qt-Variablen bei mir in der PATH-Variablen gleich nach den Windows-Verzeichnissen...

Durchsuch doch einfach mal deinen PC ob da noch weitere Qt-Dlls gefunden werden!?

Gruß,
Christian

Bin nicht selbst drauf gekommen...

Bei mir ist sowohl qt46 als auch der qtCreator1.3.1 installiert. Und siehe da: die "QtCore4.dll" gibt es in der Tat doppelt: einmal im

"C:\qt\4.6.2\bin"-Verzeichnis

und zum anderen im

"C:\qt\qt-creator-1.3.1\bin

Obendrauf sind diese noch unterschiedlich groß.

In der Pfad-Umgebungsvariablen ist sowohl der eine als auch der andere Pfad zu finden: der vom qtCreator kommt als erster.

Die Lösung war: in der "PATH"-Variablen wurde der Eintrag für das "bin"-Verzeichnis des qtCreators NACH das "bin"-Verzeichnis von qt4.6.2 gesetzt.

Und schon hat es funktioniert: auch aus Eclipse heraus geht es jetzt problemlos!

Danke Jungs!

Anmerkung:

unter windows "globale" verzeichnisse fuer qt-dlls wenn man mehrere anwendungen mit qt hat und noch selber entwickelt isss fast selbstmord ^^

besser: qt dlls gehoeren ins anwendungsverzeichnis (neben der exe) so dass die anwendung die eigenen dlls zu erst findet.
Auch in der debug Version !

Ich nab keine QTDir variable etc mehr im system. Und auch designer und Assistent ruf ich per hand auf (ausm entsprechenden bin verzeichniss).
das qt/bin Verzeichniss steht aus "sicherheitsgruenden" auch nimmer im pfad.

QTDir und co Systemvariablen werden nur vom QT plugin fuer VS loacal erzeugt. Ich hoffe der Creator macht das ebenfalls ....

Ich hab scho stundenlang nach fehlern gesucht, weil mir wer qt dlls gegeben hat ohne anzugeben gegen welche qt version gelinkt wurde, und wenn man das nimmt was im pfad steht -> aua . Tolle effekte teilweisse ^^

Übrigens mit QT_VERSION_STR bekommt man raus, welche header man grad verwendet (die statische compile version)
mit qVersion() bekommt man raus, welche Version die angezogene runtime hat.
Damit koennten viele fehler verhindert werden. Macht halt nur niemand wirklich ...
oder verwendet Ihr sowas ?

Ciao ...

Das ganze Gemurkse mit den Pfadvariablen (so einfach es auf den ersten Blick aussehen mag) scheint nicht der "Bringer" zu sein.

Mein Problem war die schlichte Tatsache, dass ich qt4.6 NACH dem QtCreator installierte.

Ich war auch verdutzt und überrascht, dass trotz der Tatsache dass ich seit Jahren mit Linux und Windows beschäftigt bin, nicht auf Anhieb alle Zusammenhänge zwischen den Komponenten der QT-Entwicklungsumgebung gefunden habe.

Es gibt zwar eine Unmenge von Beschreibungen, die ich auch nachgemacht habe: und trotzdem hat es sehr lange gedauert, bis es funktionierte.

Ist zwar nichts Schlimmes, aber einige meiner Kollegen, die gewillt waren, damit mal eben ein Paar Versuche zu machen blieben genau so stecken, wie ich.

Eigentlich schade.

Denn Visual Studio 2008 Express funktioniert auf Anhieb, und sogar ein engagierter Mechatroniker schreibt nach einem Jahr kleine Hilfsprogramme mit anonymen Delegaten in C#.

Wenn ich jetzt versuchen würde, ihm qt ans Herz zu legen und er schon am Anfang an solchen Kleinigkeiten scheitert, ist die Entscheidung klar.

Hallo!

harry_m hat geschrieben:Das ganze Gemurkse mit den Pfadvariablen...

Warum Gemurkse? Und warum soll Qt daran schuld sein?
Es ist doch bei JEDEM Programm so, dass DLL-Dateien erst im Ausführungsverzeichnis, und wenn sie da nicht liegen, in den Verzeichnissen der PATH-Variablen gesucht werden. Und die Verzeichnisse darin werden halt der Reihe nach durchsucht. Sobald die DLL dann gefunden ist, ist die Suche beendet.

Dass es z.B. eine 2te QtCore4.dll gibt, die aber eine andere Version hat, weiß das System (Windows) ja nicht. Es nimmt einfach die erste die gefunden wird.

Deswegen spricht man doch von der DLL-Hell in Windows!?

RHBaum hat geschrieben:Übrigens mit QT_VERSION_STR bekommt man raus, welche header man grad verwendet (die statische compile version)
mit qVersion() bekommt man raus, welche Version die angezogene runtime hat.
Damit koennten viele fehler verhindert werden. Macht halt nur niemand wirklich ...
oder verwendet Ihr sowas ?

Aber soweit kommt das Programm doch gar nicht, dass es überprüfen könnte dass die DLL-Version nicht stimmt, oder?!
Die Fehlermeldung tritt ja schon auf bevor die eigentliche Anwendung gestartet wurde, müsste also vom System ausgegeben werden.
Aber ich lass mich da gern eines besseren belehren, genau wissen tu ich es ja auch nicht.


Allgemein finde ich es, naja, etwas "bedenklich" wenn von jemanden eine Programmierumgebung bzw. -sprache/bibliothek vorgezogen wird, einfach weil diese es nicht erforderlich macht dass man mit gewissen Basics vertraut sein muss.
Das soll jetzt kein Angriff sein, aber ich muss mich doch ein wenig auskennen auf dem System auf dem ich arbeite bzw. für das ich eine Anwendungen erstellen möchte?!

Das ist jetzt einfach meine Meinung, wenn sie nicht gefällt, einfach ignorieren...

Gruß,
Christian

chrislo1976 hat geschrieben:...Allgemein finde ich es, naja, etwas "bedenklich" wenn von jemanden eine Programmierumgebung bzw. -sprache/bibliothek vorgezogen wird, einfach weil diese es nicht erforderlich macht dass man mit gewissen Basics vertraut sein muss.
Das soll jetzt kein Angriff sein, ...

Hier bin ich voll Deiner Meinung. Nur habe ich festgestellt, dass die lächerlichsten Hürden manchmal dafür herangezogen werden, um bestimmte Entscheidungen zu beeinflussen: weil vor den Vorgesetzten argumentiert wird, die das Fachliche nicht überblicken.

Klingt nicht nur "bedenklich", es ist sogar lächerlich, funktioniert aber (kaum zu glauben!): dennoch habe ich es öfter erlebt, dass der sog. "leichte Einstieg" zum maßgeblichen Kriterium erhoben wurde. (Nicht von mir.)

Andererseits war mein Fall ganz einfach gelagert: ich habe auf einem "jungfreulichen" WinXP, das in einer VM läuft, erst den qtCreator und dann die qt46-Umgebung installiert. Es war sonst nichts mehr im Spiel: und trotzdem gab es Probleme. In so einer Situation hätte ich von der Installationsroutine irgendein Hinweis erwartet: wenn schon bekannt ist, dass es zu Problemen führen kann.

Jungs, danke für die Unterstützung. ICH werde mich schon durchbeißen.