Build break using GCC 3.3.5

[rudi]

GCC 3.3.5 pukes on line 173 in

src\gui\kernel\qkeymapper_p.h:

enum { KeyLayoutSize = sizeof(keyLayout) / sizeof(keyLayout[0]) };

It doesn't seem to allow to declare an enum from an integer expression.

[rudi]

There seem to be more issues with GCC 3.3.5. Is that compiler version now unsupported ?

[Dmitry A. Kuminov]

The particular case you mention

#include <stdio.h>

struct KeyboardLayoutItem;
KeyboardLayoutItem *keyLayout[256];
enum { KeyLayoutSize = sizeof(keyLayout) / sizeof(keyLayout[0]) };

int main()
{
    printf("%d\n", KeyLayoutSize);
    return 0;
}

s handled well by GCC 3.3.5 here (not even a warning).

What about supporting GCC 3.3.5 in general, frankly saying I alone don't have enough resources to support two compilers (that would slow down my work significantly due to extremely big compilation times).

But I will of course check and apply your patches if you need GCC 3.3.5 and want to help with supporting it.

[Dmitry A. Kuminov]

Okay, the problem with enum initializes only appears when you put the enum definition inside a struct or a class. To my understanding, this is a bug of GCC as there should be no difference in the way how enum initializers work depending on the namespace they are in. You may now change sizeof(keyLayout) / sizeof(keyLayout[0]) (which is of course an integer constant!) to an explicit value of 256 for the time being. And btw there's a similar case in qkeymapper_pm.cpp (but the array size is different of course).

[rudi]

My machine was just not quick enough ;-). I ran into the same problem in qkeymapper_pm.cpp a few minutes later. I had another build break in line 2611 of
src\gui\kernel\qapplication_pm.cpp:

str += QString().
    sprintf(" rep %02d scan %02X ch %04X (%s) vk %04X",
            repeat, scan, ch, (ch > 32 && ch < 254) ?
            qPrintable(QString::fromLocal8Bit((char *)&ch, 1)) :
            qPrintable(QString(QChar(QLatin1Char(' ')))), vk);

While I don't really understand why my GCC barfed, I'm asking myself why this complex construct is necessary at all. According to the docs qPrintable expands to str.toLocal8Bit.constData(). So what's wrong with:

str += QString().
    sprintf(" rep %02d scan %02X ch %04X (%c) vk %04X",
            repeat, scan, ch, (ch > 32 && ch < 254) ? ch : ' ',  vk);

At the moment my build is still in progress. It's awfully slow on a network drive... I let you know, when there are more glitches coming up.

[Dmitry A. Kuminov]

That was my unsuccessful attempt to solve the wrong encoding issue in the generated line of text. qPrintable() is only suitable for LIBC's printf() which expects %s to be in the local 8-bit encoding. As opposed to that, QString::sprintf() expects %s to be an UTF-8 string, so the correct version of the line should be:

str += QString().
    sprintf(" rep %02d scan %02X ch %04X (%lc) vk %04X",
            repeat, scan, ch, (ch > 32 && ch < 254) ?
            QString::fromLocal8Bit((char *)&ch, 1).utf16() :
            QLatin1String(" ").utf16(), vk);

(note that for %c QString::sprintf() still expects Latin1 chars only, so we have to use %ls instead (not %lc because ch may probably produce more than one symbol in DBCS)).

Don't know if GCC 3.3.5 will like this construct more. (The original problem is due to the fact that it has a bunch of bugs with chained initializations from temporaries: Obj1(Obj2(Obj3(data))) etc).

[Dmitry A. Kuminov]

Oops.

[rudi]

Then I would vote for:

*QString::fromLocal8Bit((char *)&ch, 1).utf16() :
QLatin1Char(' ').unicode()

;-).

For the other problem: we could probably get around that by:

class xyz
{
        enum { KeyLayoutSize = 256 };
        KeyboardLayoutItem *keyLayout[KeyLayoutSize];
};

So we still maintain a single point in code where the size is defined.

[rudi]

Hi Dmik,

actually by accident I checked out 4.6.1 and tried to compile it with GCC 3.3.5. here is a list of changes I had to apply:

src\corelib\kernel>qmetaobject.cpp

Line 946:	QVarLengthArray<char> stackbuf(int(strlen(type)) + 1);
to:		QVarLengthArray<char> stackbuf((int)strlen(type) + 1);


src\corelib\statemachine\qabstractstate_p.h

Line 88, 89:	changed bit fields "stateType" and "isMachine" to uint and bool


src\3rdparty\freetype\include\freetype\config\ftheader.h

Line 173ff:	removed special handling for GCC3.3.5
		freetype.os2-g++.h no longer needed


src\xmlpatterns\schema\qxsdparticlechecker.cpp

Line 196:	const QSourceLocation dummyLocation(QUrl(QLatin1String("http://dummy.org")), 1, 1);
to:		const QUrl            url(QLatin1String("http://dummy.org"));
		const QSourceLocation dummyLocation(url, 1, 1);


src\plugins\graphicssystems\trace\graphicssystem_trace.cpp

Line 82:	QFileoutputFile(QString(QLatin1String("qtgraphics-%0.trace")).arg(winId));
to:		QString fileName(QLatin1String("qtgraphics-%0.trace"));
		QFile outputFile(fileName.arg(winId));

Currently there I cannot build QtScript with that setup. The problems are in 3rdparty/javascriptcore. I hve not fully figured out what's going wrong, but it's related to ISO_C99_VISIBLE and some HAVE_these_or_that #defines.

[Dmitry A. Kuminov]

I see. These are all due to bugs in GCC 3.x -- the compiler is very outdated and contains tons of bugs like this (or call it non-conformance to the standard if you will). Tell me please why do you need GCC 3.3.5 in the first place?

A second thought about maintaining compatibility brings me to a conclusion that this will be inconvenient: apparently, Qt 4.6 and above doesn't support GCC 3.x itself (since all your recent findings are in the new cross-platform code written by the Qt team) and applying these patches will additionally drag us away from the original code base which is always unwanted. And I'm pretty sure these patches will be rejected by the Qt team once we ask for merge.

So, the only thing we can do here is put this task completely up to you. It is possible to create a new repository with the external dependency on the qt4 trunk (or any branch) where you could apply your patches so that they are not lost and others who needs GCC 3.x may use them. Please tell me if you want to go this way.

[rudi]

Tell me please why do you need GCC 3.3.5 in the first place?

Actually, just because I don't want a fifth compiler on my machine(s) and the latest README.OS2 didn't say that 4.4.2 is a requirement. BTW, did you try to build Qt3 with the newer GCC ? If that worked, I could probably get rid of 3.3.5...

A second thought about maintaining compatibility brings me to a conclusion that this will be inconvenient: apparently, Qt 4.6 and above doesn't support GCC 3.x itself...

Yes, agreed.

It is possible to create a new repository...

Well, my interest in that is not so big that I would want to go that far.

[Silvan Scherrer]

as GCC 4.4.2 is the recomended and only tested one, we are not going to invest time in this. Sorry