[partly solved] Errors in cross compilation with Windows EA 7

joergs1968 · wrote on 9 May 2011, 18:06

so I started to compile QT for a yet-unsupported platform and got quite far with this, but it stopped at linking QtXmlPatterns4.dll with following strange error:

d:\qt-everywhere-opensource-src-4.7.3\src\xmlpatterns\tokenlookup.gperf(166) : fatal error C1083: Cannot open source file: 'd:\qt-everywhere-opensource-src-4.7.3\src\xmlpatterns\tokenlookup.gperf': No such file or directory

I believe this is because there is no 'gperf.exe' program available on that platform...
-are there any other such "hidden" dependencies to other GNU binaries?

p.s.
just in case you're interested, I am compiling QT for Windows Embedded Compact 7 for a Cortex-A8 (i.e. ARMV7) SoC

[update] title changed again since it's not only qmake errors that prevent a successful compilation...

[update] title changed since I found the reason for that strange behviour w.r.t. the generated sources:
the WINEA7 compiler does not like those "#line ...' directives within the generated sources; it seems it aborts compilation if the files specified there cannot be found! - commenting out those #line's in the pre-generated sources solves this issue!

koahnig · wrote on 9 May 2011, 18:21

You have to give some more details about what you are trying to achieve.
What plaform are you compiling on?
Please, provide the complete configure command line.

joergs1968 · wrote on 9 May 2011, 20:26

well, I am at home now and this problem is at work, so I cannot tell you right now the exact configure commandline, will do this tomorrow back at work...

the platform actually is/will be an evaluation board for a System-on-chip (ARMV7 Cortex-A8 architecture with onchip ATI graphix providing OpenGL ES 2.0 and OpenVG support in hardware).

operating system is the successor of WinCE 6.00/MS Auto - Windows Embedded Automotive 7.0

What I am trying to achieve is getting OpenSCAD [ http://www.openscad.org/ ] running on that evaluation board; QT is one of many pre-requisites for said OpenSCAD...
[-> http://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Building_on_Windows ]
-- but QT may be a good demonstration on its own on that evaluation board; that's why I want to get the full QT package, including all the demos and examples, running!

--
as already mentioned in my initial post: I am quite far, the QtCore4/QtGui4.dll are already build as well as the OpenGL/OpenVG components (actually everything upto QtXmlPatterns4.dll)...

just wondering if there's more than 'only' gperf missing (don't know what I need for this, there's no GNU toolchain at all there at the moment)?
--> there were a few problems along the way since WinEA7 implements some things which weren't available in WinCE6 and therfore stubbed in QT, those stubs needed to be removed - but those problems were smaller than I feared, only a couple of QT files needed to be changed so far...
(well, ok - I am constantly updating the platform configuration file [qmake.conf])

koahnig · wrote on 10 May 2011, 07:23

I had a look to the source of 4.7.3.
The file you are mentioning above is not in the directory ".../xmlpatterns" but in a subdirectory ".../xmlpatterns/parser".
I guess that the problem is not that your system does not have an exe. It is probably more a configuration error.
Since you are referring to constant updates of qmake.conf, there might be the reason combined with the newer compiler/OS used. I had to learn that the naming of directories are follwing certain conventions after I was running in some trouble with cross compilation.

My proposal is to start a new thread with a more appealing subject like: "Error in cross compilation with Windows EA 7" promoting that this is standard config.

joergs1968 · wrote on 10 May 2011, 09:49

I meanwhile installed gperf.exe on the compile-host and updated the PATH accordingly so the system should be able to find GPERF.EXE - but I am still getting this error described above!?

Is this because gperf.exe didn't exist at the time configure was executed and I must do the whole configuration / compilation to this point again? (this takes a LOT of time ...)

btw: the configuration is:
configure.exe -release -opensource -shared -ltcg -no-fast -exceptions -no-accessibility -stl
-opengl es2 -openvg -platform win32-msvc2008 -xplatform wince70embedded-armv7-msvc2008
-graphicssystem opengl -no-crt

koahnig · wrote on 10 May 2011, 10:36

I am not sure, but I think you hooked to the wrong indication for your problem.

There is a gperf.exe, which you have installed. But it does not look that this is the cause of your error. At least not in your initial post.
[quote author="joergs1968" date="1304964371"]... but it stopped at linking QtXmlPatterns4.dll with following strange error:

d:\qt-everywhere-opensource-src-4.7.3\src\xmlpatterns\tokenlookup.gperf(166) : fatal error C1083: Cannot open source file: 'd:\qt-everywhere-opensource-src-4.7.3\src\xmlpatterns\tokenlookup.gperf': No such file or directory

I believe this is because there is no 'gperf.exe' program available on that platform...
-are there any other such "hidden" dependencies to other GNU binaries?
[/quote]

Apparently, the compiler is looking for a file "tokenlookup.gperf" in directory "...\xmlpatterns".
The error code (C1083) shown is from the MS compiler, if I am not completely wrong. The compiler is trying to include a file, which is not existent.
However, the file is in a subdirectory "parser".
[quote author="koahnig" date="1305012196"]
The file you are mentioning above is not in the directory ".../xmlpatterns" but in a subdirectory ".../xmlpatterns/parser".
I guess that the problem is not that your system does not have an exe. It is probably more a configuration error.
[/quote]

BTW To my experience it is always good to redo the configure step. There must be a reason why the "make confclean" command is suggested.

joergs1968 · wrote on 10 May 2011, 11:38

[EDIT: merged this question from a separate thread here, Volker]

I configured QT 4.7.3 to do a cross-compilation to the new Windows EA 7 (embedded automotive) --which is the successor of MS Auto-- as follows:
configure.exe -release -opensource -shared -ltcg -no-fast -exceptions -no-accessibility -stl -opengl es2 -openvg -platform win32-msvc2008 -xplatform wince70embedded-armv7-msvc2008 -graphicssystem opengl -no-crt
(the target system is a cortex-A8 based SoC with an integrated ATI grafix core providing H/W accelerated OpenGL ES 2.0 and OpenVG).
I got only few problems in the beginning, mainly because unavailable functions/types/definitions that were stubbed for WinCE6 are available now and thus those stubs need to be removed plus a few issues with gesture recognition, but nothing serious ...
But now I'm stuck at a weird one:
Creating library ....\lib\QtXmlPatterns4.lib and object ....\lib\QtXmlPatterns4.exp
Generating code
d:\qt-everywhere-opensource-src-4.7.3\src\xmlpatterns\tokenlookup.gperf(166) : fatal error C1083: Cannot open source file: 'd:\qt-everywhere-opensource-src-4.7.3\src\xmlpatterns\tokenlookup.gperf': No such file or directory
LINK : fatal error LNK1257: code generation failed
NMAKE : fatal error U1077: 'D:\WINCE\sdk\bin\i386\ARM\link.EXE' : return code '0x4e9'

this 'tokenlookup.gperf' is located in a different directory than the above: it's not in ...\xmlpatterns but in ...\xmlpatterns\parser

probably that's why the build breaks here!?

I didn't had gperf.exe installed at the time when configure was executed, now I have it installed and the build process should be able to find it... (but I didn't run configure again if that matters, only updated the PATH env-var)

Don't know what to do to get this fixed, any help much appreciated!

joergs1968 · wrote on 10 May 2011, 14:04

...well, I started this second thread because this was advised by the first reply above...

anyways: I'm gonna do a clean configure again now that 'gperf' is awailable and my WinEA7 qmake.conf more-or-less stable and post here if this solves the described problem!

'til later...

goetz · wrote on 10 May 2011, 14:25

I talked to some fellow moderators, and we all agreed to merge :-)

Instead of a new post, one can always edit the subject (title) of a thread and - if necessary - ask the moderators to move it to another forum.

Good luck with your re-compilation, I'm crossing fingers...

joergs1968 · wrote on 10 May 2011, 15:59

no prob about the merge!

didn't went much further :-(
initially I got the same error, but I got around that by manually copying this TokenLookup.gperf in its parent directory...
now I'm stuck at the bison file (qquerytransformparser.cpp) - btw. I also need to install bison for windows...

qquerytransformparser.cpp
d:\qt-everywhere-opensource-src-4.7.3\src\xmlpatterns\qquerytransformparser.cpp(3364) : warning C4065: switch statement contains 'default'
but no 'case' labels
d:\qt-everywhere-opensource-src-4.7.3\src\xmlpatterns\qquerytransformparser.cpp(3142) : fatal error C1083: Cannot open source file: 'd:\qt-everywhere-opensource-src-4.7.3\src\xmlpatterns\qquerytransformparser.cpp': No such file or directory
NMAKE : fatal error U1077: 'D:\WINCE\sdk\bin\i386\ARM\cl.EXE' : return code '0x1'

very strange: it seems at the beginning that this file actually is present in that directory, but later it got deleted
-- could this be because the WinEA7 compiler extensively uses parallel compilation?
e.g. that in a sequential build this would work (1. generate the gerf/bison files, 2. compile those files, 3. delete the generated files) but the parallel building mixes up this sequence so the generated files are deleted prior being fully compiled?
-- just a thought...

(where are the makefile rules that instruct nmake/qmake to delete those generated files? so I can test this theory by commenting out those rules...)

koahnig · wrote on 10 May 2011, 16:03

@Volker
Sorry, I was not aware of how to get in touch with one of the moderators.
The intend was to draw someone else's attention to the discussion. Hope there has been some input to help joergs1968.
I guess a new configure may help, but otherwise I do not know how to continue.

koahnig · wrote on 11 May 2011, 09:41

[quote author="joergs1968" date="1305043186"]
very strange: it seems at the beginning that this file actually is present in that directory, but later it got deleted
-- could this be because the WinEA7 compiler extensively uses parallel compilation?
e.g. that in a sequential build this would work (1. generate the gerf/bison files, 2. compile those files, 3. delete the generated files) but the parallel building mixes up this sequence so the generated files are deleted prior being fully compiled?
-- just a thought...

(where are the makefile rules that instruct nmake/qmake to delete those generated files? so I can test this theory by commenting out those rules...)[/quote]

In general I would recommend to change as few as possible. Messing around with the make file rules does not sound very practical. Requiring additional installation of tools does not really like Qt. Certainly a couple of things have to be present, but what you are describing sounds strange.

You could be right that the parallel building could have some side effects. Typically I am not patient myself. Therefore, I am using extensively the parallel compilation options. However, it is probably a good choice to try it with the sequencial before investing weeks for chasing "ghosts".

However, if you start to do so, take a fresh copy of Qt and start with the configure.

joergs1968 · wrote on 11 May 2011, 12:08

I haven't messed with any makefile rules yet - I wanted to only modify those rules that delete the generated files after compilation, for pure diagnosis purposes only, that's all...

If the compilation had worked without that, I didn't need any of this!

It does not seem as if I could instruct the WinEA7 compiler to not use parallel compilation at all, so I cannot go the sequential way :-(
[ actually --according to "cl /?"-- there is an option "/MP[n] use up to 'n' processes for compilation" designed for this purpose (e.g. /MP1) -- but this doesn't seem to work, cl always complains "cl : Command line warning D9002 : ignoring unknown option '/MP'" ]

koahnig · wrote on 11 May 2011, 12:44

Sorry, I did not mean to offend you with using the words "messing around".

Concerning your problem I am at the end of my suggestions. We need to get involvement of Qt gurus. May be this is a general problem of Qt with a brand new compiler.

joergs1968 · wrote on 11 May 2011, 13:41

no offence taken, don't worry...

I got this solved/work-a-rounded: I manually invoked bison to create that qquerytransformparser.cpp from the querytransformparser.ypp input which seems to have worked finally - at least I do have a "QtXmlPatterns4.dll" now :-D

My luck doesn't lasted for long though - now I am stuck at:
src\3rdparty\javascriptcore\javascriptcore\wtf\platform.h(320) : fatal error C1189: #error : "Not supported ARM architecture"

should not be too hard to fix since ARMV7 is downward-compatible to ARMV4i, but don't know what about mixing different architectures...

[update]
since the manual compilation seems to work, it's most obviously a qmake bug, so I changed the title...

koahnig · wrote on 11 May 2011, 13:49

we are certainly at a point beyond the limits of my knowledge. We need to get Qt compilation experts involved. I have written an email to one of the moderators. This was about 15 minutes ago.

troubalex · wrote on 12 May 2011, 12:10

I passed it on to the experts. Hopefully, someone will find the time to look into it.

koahnig · wrote on 12 May 2011, 12:58

@Alexandra Thanks for your assistance.

joergs1968 · wrote on 12 May 2011, 14:26

OK - thanks for that!

I am currently dealing with some minor issues inside javascriptcore - basically because there is no min()/max() defined in the std-namespace in WINEA7; plus: I had the wrong INCLUDEPATH order, so the compiler took the system's profile.h instead of the one provided in the javascript/profiler directory...

nothing serious, I'm makeing progress...
(only takes its time - because of the latter, I need a fresh re-configure...)

[update]
ok - I got some new errors about undeclared/undefined "rel_ops" in some *.moc files, don't know what do do now, help anybody?

ThreadingQt.cpp
...src\script\tmp\moc\release_shared\threadingqt.moc(43) : error C2653: 'rel_ops' : is not a class or namespace name

(btw: I did a confclean followed by "configure -release -opensource -shared -no-fast -exceptions -rtti -no-stl -no-accessibility -opengl es2 -openvg -platform win32-msvc2008 -xplatform wince70embedded-armv7-msvc2008 -graphicssystem opengl -ltcg -qt-style-windowsce -qt-style-windowsmobile -arch windowsce -no-native-gestures")

joergs1968 · wrote on 13 May 2011, 11:10

what is this "rel_ops" error all about??

this seems to be something like a namespace identifier, but where is this comming from? why does moc.exe adds this, as this seems wrong here? - there is no such namespace existing in my compiler environment...

any help, please!