Leider tritt folgender fehler reproduzierbar auf:
Killed by SIGSEGV
pid=0x0372 ppid=0x0371 tid=0x0001 slot=0x007c pri=0x0200 mc=0x0001
C:\DEV\GCC\USR\LOCAL442\LIBEXEC\GCC\I386-PC-OS2-EMX\4.4.2\CC1PLUS.EXE
CC1PLUS 0:00303d84
cs:eip=005b:00313d84 ss:esp=0053:00a8fa1c ebp=00a8fa28
ds=0053 es=0053 fs=150b gs=0000 efl=00012202
eax=b18c9bfb ebx=fff31885 ecx=89e8ebff edx=2d26e461 edi=00000048
esi=66f47475
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.
g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
Andreas Kohl
wie sieht dein build env genau aus? Welchem gcc hast du installiert? QT4
funktioniert n�mlich wunderbar mit gcc 442
Gruss
Silvan
So wie es in der README von Qt4 4.6.2 beschrieben wird. Also das
gcc442-Paket (in Verzeichnis \dev\gcc entpackt) von netlabs und lxlite
zusätzlich.
> QT4
> funktioniert nämlich wunderbar mit gcc 442
Es fällt mir etwas schwer das zu glauben. Brauchbare Dokumentation
scheint leider völlig zu fehlen.
--
Andreas
kannst du ein ticket im svn.netlabs.org/qt4 er�ffnen?
ich weiss nicht ob das gcc442.zip alles hat was es braucht. ich habe das
nie probiert. was ich jedoch 100% sicher sagen kann, dass qt4 und auch
die apps mit gcc442 bauen. das habe ich doch schon >20 mal gemacht :)
Andreas Kohl wrote:
> Silvan Scherrer schrieb:
>
>> Andreas,
>>
>> wie sieht dein build env genau aus? Welchem gcc hast du installiert?
>
>
> So wie es in der README von Qt4 4.6.2 beschrieben wird. Also das
> gcc442-Paket (in Verzeichnis \dev\gcc entpackt) von netlabs und lxlite
> zus�tzlich.
>
>> QT4 funktioniert n�mlich wunderbar mit gcc 442
>
>
> Es f�llt mir etwas schwer das zu glauben. Brauchbare Dokumentation
> scheint leider v�llig zu fehlen.
>
> --
> Andreas
>
Silvan Scherrer schrieb:
> kannst du ein ticket im svn.netlabs.org/qt4 eröffnen?
Heute ist es schon zu spät, vielleicht morgen.
> ich weiss nicht ob das gcc442.zip alles hat was es braucht. ich habe das
Warum steht dann in der README, daß man exakt dieses Archiv nehmen soll?
Speicherverbrauch und Prozessorlast sind bei diesem Kompilierer
gigantisch - für einige Projekte reichen die knappen Ressourcen dann
nicht aus.
Die resultierenden Anwendungen starten langsam und sind auch im
Bildaufbau und Bedienung sehr träge. Vergleichbare Java-Anwendungen
wirken dagegen schon fast flink ;-)
Was muß ich ändern um einen anderen Kompilierer (icc, wpp386) verwenden
zu können?
> nie probiert. was ich jedoch 100% sicher sagen kann, dass qt4 und auch
> die apps mit gcc442 bauen. das habe ich doch schon >20 mal gemacht :)
Ich habe mal probehalber einige Versuche gemacht. Einige wenige
Programme ließen sich übersetzen. Meist ist jedoch zusätzliche
Handarbeit angesagt.
Oft reicht es aus die *.PRO-Datei zu bearbeiten, manchmal muß man die
Hindernisse in den *.CPP-Quellen ausmerzen.
Besonders nervend finde ich das vermutlich versehentliche Einbinden von
Windows-Ressourcen (ein einfaches Symbol reicht schon). Kann hier nicht
eine Prüfung erfolgen.
MfG
Andreas Kohl
> Warum steht dann in der README, da� man exakt dieses Archiv nehmen soll?
> Speicherverbrauch und Prozessorlast sind bei diesem Kompilierer
> gigantisch - f�r einige Projekte reichen die knappen Ressourcen dann
> nicht aus.
Ein Absturz von CC1PLUS.EXE - wie von Dir beschrieben - ist ein Problem
des Compilers, nicht von Qt. Warscheinlich hast Du tats�chlich ein
Ressourcenproblem. Oder auch defekten Hauptspeicher.
> Die resultierenden Anwendungen starten langsam und sind auch im
> Bildaufbau und Bedienung sehr tr�ge.
Das ist eben der Preis der Multiplatformf�higkeit. Besonders, wenn ein
System - wie z.B. OS/2 - keine gescheiten Bildschirmtreiber hat (selbst
mit SNAP ist die Performance von GpiDrawBits eine Katastrophe, teilweise
um den Faktor 3..4 langsamer als unter W*****s).
> Was mu� ich �ndern um einen anderen Kompilierer (icc, wpp386) verwenden
> zu k�nnen?
Hmm. Einen neuen Qt-Branch aufmachen und jedes Update von Nokia selbst
nachpflegen. Nicht da� ich den GCC4.4 besonders toll finde, aber er ist
f�r Qt 4.6.2 zwingend notwendig. Die Sourcen lassen sich ohne manuelle
Anpassungen bereits mit GCC3.3.5 nicht mehr �bersetzen. Hab's selbst
probiert. Die unter http://doc.trolltech.com/4.6/compiler-notes.html
gemachten Aussagen bez�glich der unterst�tzten Compilerversionen sind
ernst gemeint !
> Ich habe mal probehalber einige Versuche gemacht. Einige wenige
> Programme lie�en sich �bersetzen. Meist ist jedoch zus�tzliche
> Handarbeit angesagt.
> Oft reicht es aus die *.PRO-Datei zu bearbeiten, manchmal mu� man die
> Hindernisse in den *.CPP-Quellen ausmerzen.
Nun, Du bekommst Programme, in denen u.U. mehrere Jahre Entwicklungszeit
stecken, durch nichtmal halbt�giges Anpassen einiger Zeilen nach OS/2
'r�ber. Also was willst Du mehr ?
> Besonders nervend finde ich das vermutlich versehentliche Einbinden von
> Windows-Ressourcen (ein einfaches Symbol reicht schon).
Hmm, das Programmicon ist so ziemlich die einzige platformspezifische
Ressource, die von einem Qt-Programm verwendet wird. Wenn man ein bisher
nicht an OS/2 angepa�tes Projekt portiert, hat man eigentlich eher gar kein
Icon als das von Windows. Zumindest war das bei mir bisher immer so. Im
�brigen kann Qt intern auch Windows-Icons verwenden. Dazu wird allerdings
das zugeh�rige Imageformat-Plugin ben�tigt...
> Kann hier nicht eine Pr�fung erfolgen.
Wer sollte das denn tun ? W�re am ehesten noch der Job des Ressource-
compilers da aufzujaulen.
--
Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
http://www.s-t.de
Please remove all characters left of the "R" in my email address