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

koahnig

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

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

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

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

koahnig

@Alexandra Thanks for your assistance.

joergs1968

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

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!

joergs1968

I at least found the reason, why the build breaks for the (pre-)generated sources:

The WinCE Compiler has a strange behaviour regarding those "#line" statements which are included in the pre-generated sources and which refer to the source of the generated files:
it appears that when compiling the generated files, the filename as referred to by the #line directive, actually has to be present at that location, otherwise the build fails...
(it's sufficient to be a 0-size file with exactly that name at the referred position, but it must exist)

that's not even a new feature/bug introduced into WinEA7, WinCE6.00 (at least the MS-Auto variant) behaves exactly the same...

--> title updated!

koahnig

It does not look that there has been any feedback from Qt's experts. At least nobody from Qt besides Alexandra has added something to this thread.
That is a pitty.
I think you should file a bug report.

koahnig

I have not prepared a bug report to Qt yet, but have a look to "Contribute ":http://developer.qt.nokia.com/contribute
Apparently, you have entered new ground, but Qt's experts should be interested to understand your issues. Sooner or later thay will face those problems as well.

I am interested in the follow up, so please make sure that some sort of summary is posted, when you get additional help.

joergs1968

actually this problem regarding the broken "#line" directive seems more of a MicroSoft issue for MS Auto/Windows embedded automotive - those both do not use the PlatformBuilder for compilation but a pure commandline environment; at least in a normal (i.e. not cross-compile) VisualStudio Project, this works...
I already submitted a bug-report towards MicrosSoft, maybe they'll fix this in an upcomming release.

Actually the contribution of QT developers here is a bit disappointing :-(
-- I have more unsolved issues which I would need assistance for...

koahnig

Did you try it with a bug report to Qt?
I could imagine that Qt brains may follow some discussions, but avoid to get too much involved in the forum.

joergs1968

well - I don't see this as a Qt bug, it's more a Microsoft compiler bug...

actually the compiler-switches that I defined for my selfmade mkspec configuration were causing the trouble:
I used the same switches that I use at work for compiling, but there is a problem with the CE compiler's "/FA" switch - when this switch is defined, the "#line" directive behaves the strange way I described!
(/FA is used to let the compiler produce/keep the assembly listing; this is useful for debugging purpose but not really neccessary in Qt compilation)