Trouble installing Celestia on Linux

[cartrite]

Hi chandra, Thanks for the links. They weren't available with yast.
I did some further testing and all seems well.

cartrite

[cartrite]

The lua fixes seem to work fine but Celestia built on (at least) my Leap system, still has issues that may go beyond lua. I was trying to build lua 5.3 to install on my Leap 42.3 system. After the fix or after I go closer with my configuration of lua, I got celestia to compile but I'd get link errors with lua5.3. What I found was that somehow qt5 was ignoring pkg-config and using header files from 5.3 and linking them to lua 5.2 or 5.1 depending on which develop pkg was installed at the time. How I found this out was I got just a few linker errors while lua5.3 was installed. When I tried to uninstall 5.3, i forgot to delete the header files. When I tried to compile Celestia with lua5.3's header files still installed, I would get compile errors. Next I tried no develop package for lua 5.1 or 5.2. Then Celestia would build but get a lot of linker errors with 5.3. I tried all different flags to build a shared lib for lua 5.3 and nothing worked. Then I took a look at what openSUSE did to build the shared lib. That still didn't help.

Anyhow, I finally took a look at the make file generated by qmake. On the line that started with LIBS, I seen -L /usr/lib64. I'm not sure how that got generated. The line looked like this.

Code: Select all

LIBS          = $(SUBLIBS) -lfmt -Wl,-Bdynamic /usr/local/cspice/lib/cspice.a -llua -lm -lpng16 -ljpeg -ltheora -logg -lGLEW -lGLU -lQt5OpenGL -L/usr/lib64 -lQt5Widgets -lQt5Gui -lQt5Xml -lQt5Core -lGL -lpthread


At first, I just edited the make file generated by qmake to include /usr/local/lib64 before /usr/lib64 and linking errors were gone. There is also a -I /usr/local/include in the include path. This is what was probably causing all the issues I had with building Celestia. I'm not sure how to correct the include problem but I added this line to celestia.pro to correct the linking issue.

Code: Select all

QMAKE_LFLAGS += -L /usr/local/lib64

It seems that at least on my Leap42.3 system, that the compiler will not follow pkg-config paths and will find headers and libs and use them contrary to pkg-config when multiple versions are on this system with the same file names.

cartrite

Added after 1 hour 27 minutes:
That's not a solution or not a complete solution. It builds and links but lua does not load at runtime. I just tried cmake. It built and linked with no problems but lua still didnt load at runtime, I noticed all the libs cmake created were static or *.a, When I try to run it it trys to find lualib.so. How come it doesn't look for lualib.a? That was on there too.

I'm gonna uninstall lua53 and try the cmake with lua.5.2. That still works. Seems my Leap system doesn't like lua53. That may be why openSUSE doesn't provide it for Leap42.3.

cartrite

[selden]

cartrite,

It doesn't look for ".a" files at runtime because they are static "archive" files containing one or more concatenated ".o" files. ".a" files must be incorporated into a program's binary file when it's linked. In contrast, ".so" files are "shared object" files which get mapped to at runtime.

Does the copy of Celestia that you're working with have conditional code such that you're telling it which version of Lua you're going to be linking to? FWIW, it's my understanding that the different versions of Lua have to be referenced differently by the host program.

[cartrite]

As far as I can tell, Celestia tries to choose the most recent version or highest number. Leap doesn't provide lua53. It provides 5.2 and 5.1. I'm having trouble getting a shared lib that's built on my system to work, Lua doesn't provide shared libs and doesn't build shared libs by default. The make files that come with the source need to be modified. It's easy to build a shared lib but not so easy to get it to work.

The recent update to git master is introducing the cmake build system and I just gave it a try. I just built via cmake it with lua 5.2 installed. after I did cmake ../ from a build dir it found lua.so.5.2 so it looks like it wants to link with that at runtime. But all the output shows creatin of .a files like celengine.a . They are installed in /usr/local/lib64. This is very new to me. I wasn't expecting a .a to be loaded at runtime, I was wondering why liblua.a wasn't linked staticly during the build like everything else and why it didn't look fot liblua.a right from the start. Both versions of lua I have installed have both .a and ,so libs.

Anyhow, cmake seem to build and link with 5.2, but still won't start because of another problem. A pop-up appears stating error reading configuration file. I click on ok and celestia closes. That's with cmake.

cartrite

[onetwothree]

CMake support requires a lot of polishing and fixing.

But all the output shows creatin of .a files like celengine.a . They are installed in /usr/local/lib64.

My initial intent was to build a set of shared libs, later I made them static, but forgot to remove their installation.

I was wondering why liblua.a wasn't linked staticly during the build like everything else and why it didn't look fot liblua.a right from the start. Both versions of lua I have installed have both .a and ,so libs.

Because FindLua found .so.

Anyhow, cmake seem to build and link with 5.2, but still won't start because of another problem. A pop-up appears stating error reading configuration file. I click on ok and celestia closes. That's with cmake.

Hmm, strange. Could you run

Code: Select all

strace celestia-qt 2>&1 | grep celestia.cfg

[cartrite]

I'll give it a try when I get back. I seen this b4. When the executable doesn't get copied to the folder where the config file is.

Added after 1 hour 16 minutes:
Just tried but still got same error. Took a look at the install manifest generated by cmake and the was no celestia.cfg in that list. I seen it in the top cmake.....txt in the top dir but for some reason it was not included in the manifest.

Code: Select all

cartrite@linux-1zys:~/celestia/tmp2/Celestia/build> strace celestia-qt 2>&1 | grep celestia.cfg
open("celestia.cfg", O_RDONLY)          = -1 ENOENT (No such file or directory)

cartrite

Added after 3 hours 50 minutes:
I copied celestia.cfg to /usr/local/share/celestia and that got rid of the error pop-up. I was starting the app from a terminal and after it found the config file the teminal had a lot of output but celestia never started. cmake looks good though. Once it gets working it will be pretty cool. Different colors on the terminal.

Lua got fixed though. I found a typo in the file names. Thought that caused it but it ended up being something much simpler. I forgot about ldconfig. Ran that and lua 5.3 linked and celestia ran. tired. have a good one. cartrite

[onetwothree]

Strace is not very useful in this case, I completely forgot that celestia does chdir before loading it. I'll try to find the root cause of the issue.

[cartrite]

I took a closer look at the output created. This may change or be wrong since I didn't look at all the output. I'll give it closer look throughout today. But its trying to load .so libs.

start of output

Code: Select all

cartrite@linux-1zys:~> strace celestia-qt
execve("/usr/local/bin/celestia-qt", ["celestia-qt"], [/* 101 vars */]) = 0
brk(0)                                  = 0x21c8000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/usr/local/lib64/tls/x86_64/libtheora.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/local/lib64/tls/x86_64", 0x7ffd6c90c190) = -1 ENOENT (No such file or directory)
open("/usr/local/lib64/tls/libtheora.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/local/lib64/tls", 0x7ffd6c90c190) = -1 ENOENT (No such file or directory)
open("/usr/local/lib64/x86_64/libtheora.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/local/lib64/x86_64", 0x7ffd6c90c190) = -1 ENOENT (No such file or directory)
open("/usr/local/lib64/libtheora.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/local/lib64", {st_mode=S_IFDIR|0755, st_size=286, ...}) = 0
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=183853, ...}) = 0
mmap(NULL, 183853, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f889ccda000
close(3)                                = 0
open("/usr/lib64/libtheora.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\26\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=321904, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f889ccd9000
mmap(NULL, 2416848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f889c897000
mprotect(0x7f889c8e4000, 2097152, PROT_NONE) = 0
mmap(0x7f889cae4000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4d000) = 0x7f889cae4000
close(3)                                = 0


end of output

Code: Select all

mmap(NULL, 3444736, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f88764ec000
brk(0x2c0f000)                          = 0x2c0f000
brk(0x2c30000)                          = 0x2c30000
brk(0x2c51000)                          = 0x2c51000
mmap(NULL, 864256, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8876419000
munmap(0x7f8880108000, 856064)          = 0
close(11)                               = 0
open("data/galaxies.dsc", O_RDONLY)     = -1 ENOENT (No such file or directory)
msync(0x7f887b1da000, 10547304, MS_ASYNC|MS_INVALIDATE) = 0
munmap(0x7f887b1da000, 10547304)        = 0
write(8, "\1\0\0\0\0\0\0\0", 8)         = 8
futex(0x7f889a4037c8, FUTEX_WAKE_PRIVATE, 1) = 1
write(8, "\1\0\0\0\0\0\0\0", 8)         = 8
futex(0x2288fc0, FUTEX_WAKE_PRIVATE, 1) = 1
exit_group(1)                           = ?
+++ exited with 1 +++


cartrite

[onetwothree]

fyi, celestia.cfg installation issue is resolved

[cartrite]

Confirmed. Works great. Many Thanks. I was just about to post that the trace looked similar to Celestia_QT until it tried to load the dsc file. Then it exited with 1.

I was just about to post the only error I get while building. I still get it but it doesn't seem to mater.

Code: Select all

In file included from /home/cartrite/celestia/workarea/Celestia/build-cmake/src/celestia/qt/cotire/celestia-qt_CXX_unity.cxx:4:0:
/home/cartrite/celestia/workarea/Celestia/src/celestia/qt/qtappwin.cpp:18:17: fatal error: QIcon: No such file or directory
 #include <QIcon>
                 ^
compilation terminated.


In the compiler output it says that 5 line (s) were skipped. To look at the log for the .prefix file. That's what it said above.
That file is where it is supposed to be. But the build continues until finished.

cartrite

Added after 52 minutes 56 seconds:
I've been messing with this throughout the day and changed it to build and install shared libs. The patch for celestiacore.cpp got this running too. I'm not sure what any advantage or disadvantage it would be to have shared libs. The one thing I noticed though, Celestia_QT is just over 4 mb. celestia-qt built from the master is about 124 mb. celestia-qt built with shared libs is about 20 mb. Not sure I can understand why the Celestia_QT file is so small.

cartrite

[Janus]

@cartrite

The sizes of the files can be looked at thus.

~4Mb : Calls shared libraries. ( *.a in linux, *.dll in windows)
~20Mb : Has shared libraries statically linked in, can stand alone.
~124Mb : Probably has shared libraries statically linked in, has debugging info linked in, probably can stand alone.

GUI libraries such as QT are large, sometimes huge.

I myself prefer the middle sort myself, a plethora of support libraries is something I find annoying.


Janus.

[onetwothree]

Code: Select all

In file included from /home/cartrite/celestia/workarea/Celestia/build-cmake/src/celestia/qt/cotire/celestia-qt_CXX_unity.cxx:4:0:
/home/cartrite/celestia/workarea/Celestia/src/celestia/qt/qtappwin.cpp:18:17: fatal error: QIcon: No such file or directory
 #include <QIcon>
                 ^
compilation terminated.

That's ok.

I've been messing with this throughout the day and changed it to build and install shared libs.

Initially I intent to build everything to their own shared librarie. Later I decided to build a single libcelestia.so. It's because I want different frontends available without unnecessary binary size growth.
But due to 2 problems now I have only static libraries:
1) Visual C++. Unlike GNU G++ or CLang++ it has all symbols hidden by default, so to build DLL we need to mark almost all classes as "dllexport".
2) With a single libcelestia.so I have obscure double free errors on exit on some systems.

Celestia_QT is just over 4 mb. celestia-qt built from the master is about 124 mb

Temporary I enabled compiling and linking with debug information. https://github.com/CelestiaProject/Celestia/blob/master/CMakeLists.txt#L34

You can use strip command to remove it and celestia-qt's size will drop to 4Mb or even to 650kb if you build it with shared libraries (250kb for Gtk2, feel the difference, qt is a monster ).

[cartrite]

I confirm that. I switched over to tumbleweed. I also installed glut. So cmake made both celestia-glut and celestia-qt. Before I took out that line glut was about 190 mb and qt was over 200 mb. After glut was 3 and qt was 3.8 mb. Built from the master - the stripped line. Quite a diff. Anyhow I was playing around with an old model on Mars and noticed that celestia-glut took a long time to load the model. Almost a minute. I also noted the textures for cmods seem to need to be in the medres folder. At least that's what seems to be. Also I got a lot of textures for earth. There seems to be an issue with normal maps. When I use one on earth the water/oceans gets really bright. Unnaturally bright. Anyhow, I took a couple of screen shots of the models. Still work after all these years. Can't even remember what year I did them. I think 08 or 9?

cartrite

[SpaceFanatic64]

cartrite, can you release the Mars model? I'd like to try it out.

[cartrite]

The base model of mars is on the motherlode. The model from the first 2 images is in question. I can't remember how it was done. I think there is a 90% chance that I downloaded it frm the motherlode. I think it was Jestrs. That's still there. The vallismarineris model I think I did through blender but I can't remember where I got the data. The last 2 images I do remember they came from the Mex mission files. File H344. It had images available for red, green, and blue along with a dem file. If I can isolate my work I'll upload it. But that will take time.

Mex has a lot of files of mars and a lot of them have dems. These can be exported to cmod. I'm just trying to remember how. A lot of my posts from here and CM may shed some light. But i think most were at CM. Thats been down so....

About 6 or 7 years ago now this laptop I'm using had a hard drive failure. I lost a lot of files that documented my methods along with the data I used. Only bits remain. I still use the laptop but use usb drives. Leap is on a 1 Tb and Tumbleweed is on a 2 Tb.

cartrite.

Added after 16 minutes 30 seconds:
I vaugly remember using a number of different modeling software. Blender is what I finished them with. There was one Selden uses starts with an A. There was 3dem and Wilbur. But I evolved to use gdal to map textures and dems to create models. This is a lot more accurate.
I 'm not sure what is what though.

[SpaceFanatic64]

I think the one that starts with A is called Anim8or I believe.

[cartrite]

Yeah thats it. Blender used .obj files. Amin8or and Wilbur produced them You could also edit .obj file with a text editor. Not to edit the meshes but the header info. Like cmod in ascii format. Back in the day I used Blender to eyeball placement of models like I showed in the pics above. But as stated, I started using gdal to map the hires dems to a mapped surface dem.

Added after 12 minutes 12 seconds:
I found a folder in one of the gazillion copies of builds of celestia's extras folder. It was dated 2007. There was a read me in the folder.

This is a low resolution model of mars with moderate resolution areas of the Valles Marineris for a buffer zone to surrond the h344 model. It is an alpha model with many defects.
Just put the folder 3dmars-h344-ctx-ver4-pre into your extras folder. Any mars texture should work from their original
medres folder.There is no mars texture supplied with the model. Mars textures have to be named mars.*. Where the "*" is replaced by the file extension, jpg, png, etc.
Files in the hires folder probably will not work. All of the higher resolution areas covered by the model have there own textures in this package.

Height data from http://pds-geosciences.wustl.edu/geodata/mgs-m-mola-5-megdr-l3-v1/mgsl_300x/
The h344 model's height data from http://hrscview.fu-berlin.de/ HRSCview. Freie Universitaet Berlin and DLR Berlin
Vallesmarineris textures from ASU's themis mosaic of the Vallesmarineris. The h344.jpg texture was created with "raw" data from the CTX camera aboard the MRO spacecraft and was processed with ISIS3.

So I'll clean it up, put it through some tests, and try to upload it to the motherlode. Possibly before the end of the year.
cartrite

Added after 24 minutes 35 seconds:
I did a youtube vid a long time ago flying around that model. Just do a YouTube search h344. It should get found. Just did it.

[LukeCEL]

So I'll clean it up, put it through some tests, and try to upload it to the motherlode. Possibly before the end of the year.

Thanks so much for this! Unfortunately, parts of the Celestia Motherlode are also inaccessible right now. For example, if you try to upload a file and click the "Yes" button, it says this:

[SpaceFanatic64]

It also says that if you try to look at information for an addon.