Qt Celestia

[chris]

Thanks for that, it removes all the link errors.

Unfortunately the program still terminates immediately.

I've been building and running Celestia with Qt4.4 on the Mac, but I'm only at 4.3.3 on Windows. Maybe I'd better upgrade to 4.4 on Windows and see if something strange is happening . . .

I doubt that it makes a difference, but I build Qt4 from a Visual Studio project file instead of with nmake. You can create one by running qmake with this command line:

qmake -t vcapp celestia.pro

--Chris

[ajtribick]

Ah thanks for that.

The debug in VC++ gives the following output:

Code: Select all

'celestia-qt4.exe': Loaded 'C:\projects\celestia-svn\celestia\celestia-qt4.exe', Symbols loaded.
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\opengl32.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\msvcrt.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\advapi32.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\rpcrt4.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\secur32.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\gdi32.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\user32.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\glu32.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\ddraw.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\dciman32.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\entapi.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\psapi.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\netapi32.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\imm32.dll'
'celestia-qt4.exe': Unloaded 'C:\WINDOWS\system32\entapi.dll'
'celestia-qt4.exe': Unloaded 'C:\WINDOWS\system32\netapi32.dll'
'celestia-qt4.exe': Unloaded 'C:\WINDOWS\system32\psapi.dll'
Debugger:: An unhandled non-continuable STATUS_DLL_NOT_FOUND exception was thrown during process load
The program '[2428] celestia-qt4.exe: Native' has exited with code -1073741515 (0xc0000135).

[chris]

Ah thanks for that.

The debug in VC++ gives the following output:

Code: Select all

'celestia-qt4.exe': Loaded 'C:\projects\celestia-svn\celestia\celestia-qt4.exe', Symbols loaded.
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\opengl32.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\msvcrt.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\advapi32.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\rpcrt4.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\secur32.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\gdi32.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\user32.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\glu32.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\ddraw.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\dciman32.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\entapi.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\psapi.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\netapi32.dll'
'celestia-qt4.exe': Loaded 'C:\WINDOWS\system32\imm32.dll'
'celestia-qt4.exe': Unloaded 'C:\WINDOWS\system32\entapi.dll'
'celestia-qt4.exe': Unloaded 'C:\WINDOWS\system32\netapi32.dll'
'celestia-qt4.exe': Unloaded 'C:\WINDOWS\system32\psapi.dll'
Debugger:: An unhandled non-continuable STATUS_DLL_NOT_FOUND exception was thrown during process load
The program '[2428] celestia-qt4.exe: Native' has exited with code -1073741515 (0xc0000135).

Do you have your path set up to point to the Qt4 dlls? With my Qt4 install, I have c:\qt\4.3.3\bin appended to my PATH environment variable.

--Chris

[ajtribick]

Yes, C:\Qt\4.4.1\bin is in PATH

Would the fact that I ran qmake in the src directory (hence the .vcproj file ended up there) have anything to do with it?

[chris]

Yes, C:\Qt\4.4.1\bin is in PATH

Would the fact that I ran qmake in the src directory (hence the .vcproj file ended up there) have anything to do with it?

No, that's exactly the same way that I run it.

Did you set the PATH in a shell window or through the system control panel? Setting it in the shell window won't help if you're running in MSVC++. Assuming you've just set it in the shell, there are three things to try:
- Run celestia-qt4 from the command line (start it from the directory containing celestia.cfg)
- From the VC++ menu, select Tools/celestia-qt4 Properties. Open the configuration properties node, then open the debugging node. Add this line to the Environment setting:
PATH=%PATH%;c:\qt\4.4.1\bin
- Or, just add c:\qt\4.4.1\bin to your path in the system control panel (a headache, because it requires a system restart.)

--Chris

[ajtribick]

I did it via the Control Panel+restart, still no luck.

[chris]

I did it via the Control Panel+restart, still no luck.

I'm very puzzled as to what the missing DLLs are then. I assume that you've already looked to verify that there actually are DLLs in c:\qt\4.4.1\bin . . . Are you building the debug or release version of Celestia-qt4?

When I get back home to my Windows machine in a couple hours, I'll take a look at the sequence of DLLs loaded at start time.

--Chris

[ajtribick]

Ok, still no luck.

Are there any instructions for building from a clean SVN download on Windows, including what extra files are necessary and where they should go?

(Never knew Windows was so complicated, on Linux everything just works, with the exception of my wireless card...)

[chris]

Ok, still no luck.

Are there any instructions for building from a clean SVN download on Windows, including what extra files are necessary and where they should go?

(Never knew Windows was so complicated, on Linux everything just works, with the exception of my wireless card...)

I've upgraded to Qt 4.4.1 and built without any troubles on my Windows machine. It might be worth running depends.exe on your compiled exe:
http://www.dependencywalker.com/

It will help pinpoint any missing (or possibly incompatible) DLLs that are causing grief. You can even run the app in profile mode and watch what DLLs are accessed. One possible problem that I didn't think to mention before is that the Celestia support DLLs--libpng.dll, etc.--may not be installed in the same directory as the exe.

--Chris

[cartrite]

You can try these libs. These are what I use to build the QT4 version of Celestia without any problems. It works without any problems when building from the vcproj file generated by qmake.
In a more recent post, viewtopic.php?p=107593#p107593, Chris made some libs available so I deleted the qt4libs that I use from this post.
cartrite

[ajtribick]

Hmmm... dependency walker claims the problem is that I am missing libpng1.dll... where's a safe place to get that from?

[ajtribick]

Aha got it (almost) working, though apparently the version of libpng1.dll I've got isn't the right one, because PNG textures do not seem to work.

The program also runs really slowly...

I am confused as to why the Qt version needs libpng1.dll to display PNG textures when the Windows version doesn't (plus, there are no libpng1.dll, zlib.dll files in my Celestia windows installation and that seems to work fine...)

[ElChristou]

Chris, a Qt version can be build for osX right now? (last time I tried I get some kind of error - don't remember exactly)

[t00fri]

Aha got it (almost) working, though apparently the version of libpng1.dll I've got isn't the right one, because PNG textures do not seem to work.

The program also runs really slowly...

I am confused as to why the Qt version needs libpng1.dll to display PNG textures when the Windows version doesn't (plus, there are no libpng1.dll, zlib.dll files in my Celestia windows installation and that seems to work fine...)

I compiled libpng.dll myself for Windows (VC 2003.net), in order to have exactly the same DLL settings etc as for the Celestia compilation itself. I never had any problems to build Qt Celestia SVN under Windows.

Fridger

[chris]

Aha got it (almost) working, though apparently the version of libpng1.dll I've got isn't the right one, because PNG textures do not seem to work.

The program also runs really slowly...

Usually, this is a symptom that you're running with software OpenGL. But if that were the case, Celestia built with the native Win32 UI would also run very slowly. Perhaps there are a lot of errors being generated?

I am confused as to why the Qt version needs libpng1.dll to display PNG textures when the Windows version doesn't (plus, there are no libpng1.dll, zlib.dll files in my Celestia windows installation and that seems to work fine...)

The Windows version uses statically linked versions of these libraries. I've been using them with the Qt4 version as well; it probably makes sense to make this the 'official' build approach, as it means one less thing to explain and one less thing to break. You don't even need to modify celestia.pro. Just replace the lib files with these:

http://www.celestiaproject.net/~claurel/celest ... iclibs.zip

Now, these libs will *not* work with the Windows version of Celestia. That's because Celestia-Qt4 is built with MSVCRT (dynamic, multithreaded C++ runtime), while the Windows version of Celestia is built with LIBCMT (static, multithreaded C++ runtime.) Since the Qt4 libraries are by default built against MSVCRT, Celestia-Qt4 and all dependent libraries must be as well. I have't tried building Qt4 with LIBCMT; all that's necessary is to change two lines in mkspecs\win32-msvc2008\qmake.conf:

From:

Code: Select all

QMAKE_CFLAGS_RELEASE    = -O2 -MD
QMAKE_CFLAGS_DEBUG      = -Zi -MDd


To:

Code: Select all

QMAKE_CFLAGS_RELEASE    = -O2 -MT
QMAKE_CFLAGS_DEBUG      = -Zi -MTd


It should work, but since it's not the default for Qt4, we're just building everything with MSVCRT.

If you think all of this sucks, you're right. But, it's nowhere near as much of a nightmare as actually deploying an app built with a recent version of MSVCRT and getting it to use the right DLLs.

--Chris

[cartrite]

Back a while ago I noticed something about icons.qrc not found by rcc in the Linux QT4 build. I was trying to fix this but I can't remember how this was done.
I always got this error but I ignored it because Celestia was still built and was able to run. I can navigate to the celestia/qt folder and run rcc manually and get the .cpp file produced by windows qt4.
cartrite

[cartrite]

I'm not sure why the first line of output says that icons.qrc cannot be found. But it is found and it is the last object file to be built. So never mind. Must be a Linux thing.
cartrite

[cartrite]

I've been experimenting with the qt4 gui and noticed just the other day that the celestia executable was about 49 mb. This probably has to do with CFLAGS and CXXFLAGS. I put these into all the .pro files. I haven't tried it yet with the celestia.pro file that comes with svn.

Code: Select all

DEFINES += CELX LUA_VER=0x050100
DEFINES += GLEW_STATIC
DEFINES += USE_SPICE
DEFINES += EIGEN_NO_DEBUG
DEFINES += \
   NDEBUG \
   NO_DEBUG

QMAKE_CXXFLAGS_RELEASE = \
   -ffast-math \
   -fexpensive-optimizations \
   -fomit-frame-pointer \
   -msse2 -O2

QMAKE_CFLAGS_RELEASE = \
   -ffast-math \
   -fexpensive-optimizations \
   -fomit-frame-pointer \
   -msse2 -O2

QMAKE_CXXFLAGS_MT += -MT

QMAKE_CFLAGS_MT += -MT


This is because I tried building qt4 another completely different way. In the top directory, I just have a file called celestia.pro that is quite small and controls the build process. It has the TEMPLATE variable defined as subdirs. Then every top src folder has a .pro file in it that has the name of the folder. For example, src/celutil has a celutil.pro file in it. The folders celutil, celtxf, celmath, cel3ds, and celengine have .pro files the have the TEMPLATE variable defined as libs. They are also set to staticlibs in the CONFIG variable. The src/celestia has a file called again celestia.pro and the TEMPLATE variable is defined as app. This builds the application and links the static libs built earlier to it. Unfortunately, after building this way, the executable was still 49 mb. That's when I put in the CFLAGS and CXXFLAG options. The executable is now down to 4.9 mb and the frame rates are still quite good.
cartrite

[chris]

It's important that NDEBUG and NO_DEBUG are only defined in the release build. You should be able to do this by placing a scope around the statement that adds them:

Code: Select all

release {
   DEFINES += \
      NDEBUG \
      NO_DEBUG
}


--Chris

[cartrite]

There are also a lot of scope statements missing for win32, unix, and mac. But I got no way to test those platforms.

I don't know if debug was affecting the file size though. I was putting "release" in the CONFIG variable and it did nothing. Still the executable was 49 mb. Another thing, when I took out the -fomit-frame-pointer option, the fps when to hell. I was getting 11 or so fps just looking at the earth. Without -O2 I was getting around 60 fps. But after I put in -O2, The fps went back to 200 +.
cartrite