Qt Celestia

[Vincent]

Fridger, Cartrite,

Thanks !

Actually, I didn't use the VS 2005 GUI, but I wrote my own batch file to set the VS 2005 environment:

Code: Select all

@echo off

"%VS80COMNTOOLS%vsvars32.bat"

cd C:\Program Files\Microsoft SDK
SetEnv.Bat

cd celestia-qt

And everything worked like a charm.

[t00fri]

While in Release mode the compilation works perfectly with my VS2003.Net compiler, in Debug mode there are 2 persistent errors in celutil/debug.cpp

--------------------------------------------------------------
celutil\debug.cpp(33) : error C3861: 'IsDebuggerPresent': identifier not found, even with argument-dependent lookup
celutil\debug.cpp(37) : error C2664: 'OutputDebugStringW' : cannot convert parameter 1 from 'char [1024]' to 'LPCWSTR'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
--------------------------------------------------------------
The second error goes away by replacing in line 37 of debug.cpp

OutputDebugString(buf); ==>
OutputDebugString((LPCWSTR) buf);

About the first error, I have no idea. The header windows.h should do the job, but...

Chris?
How does it go with Vs2005 express?

F.

[chris]

While in Release mode the compilation works perfectly with my VS2003.Net compiler, in Debug mode there are 2 persistent errors in celutil/debug.cpp

--------------------------------------------------------------
celutil\debug.cpp(33) : error C3861: 'IsDebuggerPresent': identifier not found, even with argument-dependent lookup
celutil\debug.cpp(37) : error C2664: 'OutputDebugStringW' : cannot convert parameter 1 from 'char [1024]' to 'LPCWSTR'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
--------------------------------------------------------------
The second error goes away by replacing in line 37 of debug.cpp

OutputDebugString(buf); ==>
OutputDebugString((LPCWSTR) buf);

About the first error, I have no idea. The header windows.h should do the job, but...

Chris?
How does it go with Vs2005 express?

F.

I haven't tried VS2005 express yet--I'm still working with MinGW. I want to make a few more refinements to the Deep Sky browser, then I'll try switching compilers. There's also the matter of finishing 1.5.0

The errors you're seeing are caused due to the fact that building with Qt4 turns on Unicode support, and all the Win32 functions that accept strings are mapped to the wide character versions. One workaround is to change OutputDebugString to OutputDebugStringA to explicitly use the ASCII version of the function.

--Chris

[t00fri]

...
The errors you're seeing are caused due to the fact that building with Qt4 turns on Unicode support, and all the Win32 functions that accept strings are mapped to the wide character versions. One workaround is to change OutputDebugString to OutputDebugStringA to explicitly use the ASCII version of the function.

--Chris

Yes, that also works, but still the other error remains:

e:\Cvs\celestia\src\celutil\debug.cpp(33): error C3861: 'IsDebuggerPresent': identifier not found, even with argument-dependent lookup

F.

[ElChristou]

...I actually have also incorporated LUA-5.1 and cspice again, such that I can use Chris' start.celx for the Qt-GUI. start.celx is much nicer.

There are a few variables in qmake like DEFINES that allow very easily to reactivate lua and cspice...

You are talking about your sandbox or CVS?
(I ask because it would be nice if we could sync all platforms; actually I think celx still don't work on osX).

[cartrite]

...
The errors you're seeing are caused due to the fact that building with Qt4 turns on Unicode support, and all the Win32 functions that accept strings are mapped to the wide character versions. One workaround is to change OutputDebugString to OutputDebugStringA to explicitly use the ASCII version of the function.

--Chris

Yes, that also works, but still the other error remains:

e:\Cvs\celestia\src\celutil\debug.cpp(33): error C3861: 'IsDebuggerPresent': identifier not found, even with argument-dependent lookup

F.

I get the same 2 errors when I compile the vcproj file generated by qmake in debug. And I can also fix the second error with Chris's suggestion.
I don't get any errors when I build the vcproj file in debug from cvs.
It seems that the _WIN32_WINNT define is not being passed into the debug version. When I looked at the build log, it was not in the output. I tried fooling with the qmake.conf file but got nowhere.
cartrite

[t00fri]

...
The errors you're seeing are caused due to the fact that building with Qt4 turns on Unicode support, and all the Win32 functions that accept strings are mapped to the wide character versions. One workaround is to change OutputDebugString to OutputDebugStringA to explicitly use the ASCII version of the function.

--Chris

Yes, that also works, but still the other error remains:

e:\Cvs\celestia\src\celutil\debug.cpp(33): error C3861: 'IsDebuggerPresent': identifier not found, even with argument-dependent lookup

F.

I get the same 2 errors when I compile the vcproj file generated by qmake in debug. And I can also fix the second error with Chris's suggestion.

Aha, what exactly did you do in celutil/debug.cpp??
I just replaced in line 37
OutputDebugString(buf) =======> OutputDebugStringA(buf);

I don't get any errors when I build the vcproj file in debug from cvs.

Note I only get the errors when I compile the code in debug mode...

F.

[cartrite]

I didn't do anything. I only got the 2 errors when I tried to compile the qt4 version in debug. When I compiled the vcproj file in the root dir from cvs, I got no errors in debug without changing anything.

To fix the error

celutil\debug.cpp(37) : error C2664: 'OutputDebugStringW' : cannot convert parameter 1 from 'char [1024]' to 'LPCWSTR'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast

I did the same thing you did.

I just replaced in line 37
OutputDebugString(buf) =======> OutputDebugStringA(buf);

cartrite

[cartrite]

When I make this change to WinBase.h the debugging error goes away.
For some reason, the test for _WIN32_WINNT >= 0x0400 is failing and it does not get defined.

Code: Select all

//#if (_WIN32_WINNT >= 0x0400) || (_WIN32_WINDOWS > 0x0400)
//WINBASEAPI
//BOOL
//WINAPI
//IsDebuggerPresent(
//    VOID
//    );
//#endif

WINBASEAPI
BOOL
WINAPI
IsDebuggerPresent(
    VOID
    );

All I did was copy the code inside the if statement and commented out the entire if statement. I know this is not a fix but it may give some insight to one. I think that qmake.conf needs to be changed. But I don't know what that change could be.



cartrite

I don't know why this didn't work before. I got a gizillion errors. Must have had a typo.
But this time it worked. I inserted this on the DEFINES line in qmake.conf

Code: Select all

_WIN32_WINNT=1400

That got rid of the error. No changes to WinBase.h were needed.
cartrite
Actually, this also works and it is probably safer.

Code: Select all

DEFINES         += UNICODE WIN32 QT_LARGEFILE_SUPPORT _WIN32_WINNT=0x400


cartrite

[cartrite]

I didn't realize that celestia.vcproj could be viewed with a text editor.
This is why the cvs version of the file worked for debug and the one generated by qmake didn't.

PreprocessorDefinitions="CELX;LUA_VER=0x050100;USE_SPICE;WINVER=0x0400;_WIN32_WINNT=0x0400;_CRT_SECURE_NO_DEPRECATE"

Here is what that line looks like in celestia-qt4.vcproj that was generated by qmake.

PreprocessorDefinitions="_WINDOWS,UNICODE,WIN32,QT_LARGEFILE_SUPPORT,QT_DLL,QT_OPENGL_LIB,QT_GUI_LIB,QT_CORE_LIB,QT_THREAD_SUPPORT"

cartrite

[t00fri]

I didn't realize that celestia.vcproj could be viewed with a text editor.
This is why the cvs version of the file worked for debug and the one generated by qmake didn't.

PreprocessorDefinitions="CELX;LUA_VER=0x050100;USE_SPICE;WINVER=0x0400;_WIN32_WINNT=0x0400;_CRT_SECURE_NO_DEPRECATE"

Here is what that line looks like in celestia-qt4.vcproj that was generated by qmake.

PreprocessorDefinitions="_WINDOWS,UNICODE,WIN32,QT_LARGEFILE_SUPPORT,QT_DLL,QT_OPENGL_LIB,QT_GUI_LIB,QT_CORE_LIB,QT_THREAD_SUPPORT"

cartrite

many thanks cartrite,

that seems to be the reason that _WIN32_WINNT is apparently unset, here. Then the definition of IsDebuggerPresent() is lacking etc...

I'll try this out tonight when I get home.

I have another not very important "abnormality" in my Vs2003.Net GUI:

Normally, after compiling, one starts the application withing the VS2003 GUI by clicking Debug->Start without Debugging. While Celestia works fine when started from e.g. the console or from Windows Explorer, it crashes without comment, if started via the Debug->Start without Debugging menu entry. This might not be unrelated to the previous issue... This works all fine with my usual compilation of Celestia (no Qt!)

F.

[cartrite]

Fridger,
Youl'll notice that the vcproj file from cvs has

CELX;LUA_VER=0x050100;USE_SPICE;WINVER=0x0400

Are these needed in the vcproj file generated by qmake to build spice and lua support?
I changed my qmake.conf to look like this

Code: Select all

DEFINES         += UNICODE WIN32 QT_LARGEFILE_SUPPORT CELX LUA_VER=0x050100 USE_SPICE WINVER=0x0400 _WIN32_WINNT=0x400

and changed the celestia.pro file to include the extra libs and header folders.
I'm not sure if I need that in qmake.conf or not.
cartrite

[cartrite]

Activating Lua and spice gave me a lot of link errors.
This led me to look at the celestia-qt4.vcproj file and I noticed something else wrong. The linker had the release libs listed and not the debug libs in the debug area.
cartrite

[t00fri]

Fridger,
Youl'll notice that the vcproj file from cvs has

CELX;LUA_VER=0x050100;USE_SPICE;WINVER=0x0400

Are these needed in the vcproj file generated by qmake to build spice and lua support?
I changed my qmake.conf to look like this

Code: Select all

DEFINES         += UNICODE WIN32 QT_LARGEFILE_SUPPORT CELX LUA_VER=0x050100 USE_SPICE WINVER=0x0400 _WIN32_WINNT=0x400

and changed the celestia.pro file to include the extra libs and header folders.
I'm not sure if I need that in qmake.conf or not.
cartrite

cartrite,

yes these DEFINES are for lua and spice. The best is to add them into
the project file rather than in qmake.conf as

DEFINES = CELX LUA_VER=0x050100 USE_SPICE

separated by BLANKS and without trailing -D's! You might need
another variant of the LUA_VER definition, depending on the LUA lib
you are using.

I would not add macros to qmake.conf that are dependent on a
particular program! For these things the .pro project file is meant.

Things work very well for me after I updated of course the project file
with FOUR .cpp files + respective headers that are using LUA:


celestia/celx.cpp \

celengine/scriptobject.cpp \
celengine/scriptorbit.cpp \
celengine/scriptrotation.cpp \

and the same for the headers.

Then you must also add the lua and spice libs and includes here
(towards the bottom of the project file)


win32 {
INCLUDEPATH += \
../inc/libintl \
../inc/libz \
../inc/libpng \
../inc/libjpeg
../inc/lua-5.1 \
../inc/spice
LIBS += -L../lib \
-lzlib \
-llibpng \
-llibjpeg \
-lintl \
-llua \
-lspice
}

++++++++++++++++++++++
I do these changes in another copy of celestia.pro, called
celestia-lua.pro, that will NOT be updated when Chris commits further
changes.
++++++++++++++++++++++

If things don't work for you I can send you my celestia-lua.pro file.
Note that the names of your includes and libs may differ!


F.

[cartrite]

Thanks Fridger,
I already have been using a different .pro file with the extra libs and headers but I never activated lua and spice in the qmake.conf file. I did forget to add the extra .cpp and .h files to the .pro file. I had to add the 2 spice .cpp's along with the ones you posted. But this still gave me link errors. There was a conflict between libcmt.lib and msvcrt.lib. I tried to NODEFAULTLIB:msvcrt but that gave me a link error on every file. So I tried

Code: Select all

QMAKE_LFLAGS      = /NOLOGO /NODEFAULTLIB:libc /NODEFAULTLIB:libcmt

and that worked. This is really getting crazy.
Thanks again,
I would have never thought about the missing .cpp and .h files from celestia.pro.

yes these DEFINES are for lua and spice. The best is to add them into
the project file rather than in qmake.conf as

DEFINES = CELX LUA_VER=0x050100 USE_SPICE

I had a lot of syntax problems trying to add vaiables to the celestia.pro files.
Is this really better? I have 3 different qmake.conf files in the mkspec/default dir. I have one for debug-qmake.conf, lua-and-spice-qmake.conf, and the original-qmake.conf. I just rename the one I want to use to qmake.conf.
cartrite

[cartrite]

I would not add macros to qmake.conf that are dependent on a
particular program! For these things the .pro project file is meant.

Now that I got different .pro files to do the different tasks that work ( I went back to using the original qmake.conf and all changes are in the .pro files ), I like this idea. Some time in the future I'll probably want to use qmake for something else and forget that I played around with the files. Then I'll go crazy trying to figure out why it don't work.
Thanks Again.
cartrite

[Andy74]

Hi all,

I tried to compile Qt 4.3.3 according to Fridger's instructions. Usually, following any of Fridger's instructions works very well -- but unfortunately not this time for me ...

I use the Visual C++ 2005 express edition with the platform SDK 2003 R2.
My operating system is Windows XP (Home).
After uncompressing the Qt-4.3.3 package, running configure worked without problems.
Then nmake produces the following error message (in a dialog box, not in the console):

Code: Select all

[Microsoft Visual C++ Runtime Library]
Runtime error!
Program: D:\Qt\4.3.3\bin\moc.exe
R6034
An application has made an attempt to load the C runtime library incorrectly.
Please contact the application's support team for more information.
[OK]


nmake's output before the error is as follows:

Code: Select all

   cd src\winmain\ && nmake -f Makefile
   nmake -f Makefile.Debug all
   nmake -f Makefile.Release all
   cd src\tools\moc\ && nmake -f Makefile
   nmake -f Makefile.Release
   cd src\tools\rcc\ && nmake -f Makefile
   nmake -f Makefile.Release
   cd src\tools\uic\ && nmake -f Makefile
   nmake -f Makefile.Release
   cd src\corelib\ && nmake -f Makefile
   nmake -f Makefile.Debug all
   D:\Qt\4.3.3\bin\moc.exe -DQT_SHARED -DQT_THREAD_SUPPORT -DUNICODE -DWIN32 -DQT_LARGEFILE_SUPPORT -DQT_BUILD_CORE_LIB -DQT_MAKEDLL -DQT_ASCII_CAST_WARNINGS -DQT_44_API_QSQLQUERY_FINISH -DQT3_SUPPORT -DQT_MOC_COMPAT -D_USE_MATH_DEFINES -DQT_DLL -I"..\..\include" -I"..\..\include\QtCore" -I"tmp" -I"global" -I"..\3rdparty\zlib" -I"d:\Qt\4.3.3\include\ActiveQt" -I"tmp\moc\debug_shared" -I"." -I"..\..\mkspecs\win32-msvc2005" -D_MSC_VER=1400 -DWIN32 io\qbuffer.h -o tmp\moc\debug_shared\moc_qbuffer.cpp


Reading this thread carefully and searching the forum didn't give me a hint.
Any help is much appreciated!

Thanks
Andy

[cartrite]

Andy74,
Are you sure you have Platform SDK 2003 server sp1? I downloaded this and Visual C++ 2005 express edition the other day and didn't have any problems building QT4.3.3. I also built QT4 from the Visual C++ 2005 express command prompt. I also built QT4 BEFORE Visual C++ 2005 express edition was updated to SP1 the next day by Windows Update. If you built from the GUI, There was a setup procedure that modified the path,s in Visual C++ 2005 express to put the Platform SDK 2003 folders before the Visual C++ 2005 folders.
See here. http://www.celestiaproject.net/forum/viewtopic ... 8552#98552

But this is what I did to get the QT4 build to work. http://www.celestiaproject.net/forum/viewtopic ... 8506#98506

I think? maybe Chris also had problems building QT4 with Visual C++ 2005 express? That may be why he is using MinGW.
cartrite

[chris]

Andy74,
Are you sure you have Platform SDK 2003 server sp1? I downloaded this and Visual C++ 2005 express edition the other day and didn't have any problems building QT4.3.3. I also built QT4 from the Visual C++ 2005 express command prompt. I also built QT4 BEFORE Visual C++ 2005 express edition was updated to SP1 the next day by Windows Update. If you built from the GUI, There was a setup procedure that modified the path,s in Visual C++ 2005 express to put the Platform SDK 2003 folders before the Visual C++ 2005 folders.
See here. http://www.celestiaproject.net/forum/viewtopic ... 8552#98552

But this is what I did to get the QT4 build to work. http://www.celestiaproject.net/forum/viewtopic ... 8506#98506

I think? maybe Chris also had problems building QT4 with Visual C++ 2005 express? That may be why he is using MinGW.
cartrite

I haven't tried VS 2005 with Qt4 yet--I've been too busy on the 1.5.0 release lately. After 1.5.0 final is out, I'll try to get up and running on VS 2005, then maybe give VS 2008 a try.

--Chris

[cartrite]

I haven't tried VS 2005 with Qt4 yet--I've been too busy on the 1.5.0 release lately. After 1.5.0 final is out, I'll try to get up and running on VS 2005, then maybe give VS 2008 a try.

OK. For some reason I thought you had problems building QT4 and that is why you used the MinGW version.
cartrite