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

@Alexandra Thanks for your assistance.

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”)

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!

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!

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.

I have not prepared a bug report to Qt yet, but have a look to Contribute [developer.qt.nokia.com]
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.

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…

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.

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)