Missing QtCore exports

[rudi]

Attempting a full rebuild (no shadow) fails when linking QtXml due to missing exports from QtCore. Several symbols (like QByteArray::QByteArray(const char *) are not exported anymore. The newly created QtCore.lib is smaller than it used to be.

Shadow build fails even earlier. QMake can't be built due to missing include path (qstringlist.h not found).

[Dmitry A. Kuminov]

Hmm. Nothing like that here. Been doing full (shadow) rebuilds all the time for the last couple of days.

[Dmitry A. Kuminov]

Regarding the QMake build failure, looks like headers were not copied over to your build directory for some reason. This is performed *before* building qmake. Do you have Perl? Please give me the full output of configure.cmd on a clean build directory.

[rudi]

Oops, I though I had Perl in the path, however I was using a different startup batch file... So this is not a problem. BTW, I'd suggest to start the copying after the user has agreed to the license, not before.

However, I still cannot build QtXml. The same missing exports as in the non-shadow case. Some more examples for missing symbols are the destructors of QRegExp, QBuffer and QTextDecoder.

[rudi]

Update: The missing symbols are most likely a bug of GCC 4.5.2, which I tried for the first time. Back to 4.4.4 and everything appears to be fine...

[Dmitry A. Kuminov]

So, you changed the compiler. Welcome to the club -) It is known, there are bugs in handling of dllexport in GCC 4.5.2 which prevent Qt from building. Paul is aware of that: ​http://mantis.smedley.info/view.php?id=474.

Regarding Perl, configure.cmd should check for perl existence and report an error if it can't find Perl or if the script fails (just checked -- it works). Are you sure you haven't seen it?

[Dmitry A. Kuminov]

Okay, I see the problem. As opposed to the classical .CMD scripts, the absence of the explicit 'exit' statement the REXX scripts doesn't cause it to return the last exit code (e.g. from a failed child), an explicit 'exit rc' statement is necessary. I fixed this for the syncqt wrapper created by configure.cmd in r988 (but if Perl on your side is a REXX script itself which doesn't do 'exit rc', the error will be lost anyway -- we can't do anything here).

[rudi]

Looks like it's a different problem than the one you describe in comment:5. There is no _System calling convention / name decoration involved. It just fails to export some symbols.

[rudi]

I just nocticed another stupid problem with the shadow build. Here the files qconfig.h and QtConfig in <build_dir>/include/QtCore have a file date of 1.1.2098. This is unfortunate when it comes to make. Looks like a bug in Perl...

[Dmitry A. Kuminov]

If you read carefully the GCC bug (the first note) you will see that I talk about dllexport there. The title of the bug is not correct.

Regarding Perl. Yes, I noticed that too. The reason is that the original qconfig.h file the forwarders refer to, does not yet exist (the syncqt script even emits a warning in such a case) as according to configure logic it is created at a later stage. So, as a solution, in r995 I now create an empty dummy qconfig.h before executing syncqt. Its date will be a few minutes earlier than the real config.h but for the make sake it's OK -- the problem only takes place where you initiate the build directory for the first time (nothing is built anyway), subsequent runs of syncqt will take the actual date of qconfig.h if it gets changed (or leave the forwarder untouched). This also fixes the Perl warning about an uninitialized variable at line 337 (a cross-platform bug in syncqt).

And probably it's a bug in Perl indeed. utime(), being passed a null timestamp should set the time to 01-01-1980 (the "epoch" start on OS/2).