Page 1 of 1

Installing Celestia on Linux - Kubuntu 17.10

Posted: 10.12.2017, 11:47
by ssab

I am looking to install Celestia under the latest version of Kubuntu. Unfortunately it is not featured in the repositories.

Can anyone help me figure out the best way ? I'm not so familiar with the manual installations and compiling, and I'd like if possible to use a minimal amount of secondary software.

Many thanks.

Added after 29 minutes 3 seconds:
I have attempted two main solutions :

One exposed here :
But it requires a huge amount of additional software for the make process.

And the one exposed in the userguide :
Linux Operating Systems:
Most distributions package Celestia to best suit their users' needs. Check with your package management software, as there is a good chance that Celestia is present there.
Alternatively, there is a precompiled x86 AutoPackage provided on the SourceForge download site.  This package uses the GTK+ front-end, and should run on most computers.  Information about installing an AutoPackage is here:
Finally, should you wish to compile Celestia yourself, the process is fairly straightforward.  Unpack the tarball:
Then change directory (cd) into the newly created directory and configure Celestia.  Run configure with the appropriate command line for the version that you want to compile:

Code: Select all

    ./configure --with-kde
    ./configure --with-gnome
    ./configure --with-gtk

The configure script may complain if you are missing a required component, or if you have an out of date version of a required component. Check the error output to determine what's missing, install the necessary items, and then try re-running configure.  If neither the KDE or GNOME versions of Celestia will build, try falling back to the GTK+ version. There are many options for configure; you can view them all with a brief explanation for each-by running ./configure --help. After running configure, compile and install Celestia:

Code: Select all

    make install

Note:  make install will need to be run as root unless you've overridden the default install directory by invoking configure with the --prefix option.

However when I run ./configure --with-kde I get the following error (both with sudo and as normal user) :

Code: Select all

configure: error: in `/home/sylvain/Documents/Applications/celestia-1.6.1':
configure: error: no acceptable C compiler found in $PATH
See `config.log' for more details

Posted: 10.12.2017, 17:08
by selden
Unfortunately, at the moment, building Celestia from source code for a Linux platform requires intimate knowledge of the software development environment for your chosen distro. That particular error message seems to be indicating either that you don't have a C++ compiler installed (and thus probably are missing some of the other supporting tools) or that it's looking for a different version of the compiler. You'll have to investigate the contents of the configure file to find out which.

John Van Vliet has been building Celestia so it runs under SUSE, his favorite Linux distro. I managed to persuade an earlier (non-Qt) version of his GitHub development tree to build under Scientific Linux v7. The Qt version doesn't build, though, and I haven't wanted to spend the time to find out why. You might have better luck with it, though. See

Alternatively, a quick Web search located what seemed to be various Celestia binaries for Ubuntu, available for direct download, not from a repo. You might want to consider one of them.

See, for example,

Posted: 11.12.2017, 08:21
by Alexell
KDE, GNOME, GTK will no longer be supported.
You need to compile using --with-qt

Posted: 11.12.2017, 22:24
by John Van Vliet
at this time i do NOT provide linux binaries
mainly because i like rpm based package managers
and REFUSE to make 20 different binaries

the fork i have on my github page is QT5 based
you can run qt gui's under gtk just like you can run gtk gui's under qt

as selden pointed out you did not install the ubuntu "build tools" and "development tools"

Once you install the debian " Build Essentials " and lua5.1 and lua5.10dev( 5.1 is MANDATORY ) libpng and libpng-dev
and Qmake5 installed and the qt5 development tools

and a few others that autotools will tell you about

grab a zip from my fork and cspice from NAIF

this should build on 17.04 long term support or the very short lifespan 17.10

Posted: 25.02.2018, 03:39
by ttguy
John Van Vliet wrote:at this time i do NOT provide linux binaries
mainly because i like rpm based package managers
and REFUSE to make 20 different binaries

the fork i have on my github page is QT5 based
you can run qt gui's under gtk just like you can run gtk gui's under qt

as selden pointed out you did not install the ubuntu "build tools" and "development tools"

Once you install the debian " Build Essentials " and lua5.1 and lua5.10dev( 5.1 is MANDATORY ) libpng and libpng-dev
and Qmake5 installed and the qt5 development tools

and a few others that autotools will tell you about

grab a zip from my fork and cspice from NAIF

this should build on 17.04 long term support or the very short lifespan 17.10

So I just used the info in this post to build this on Kubuntu 16.04 - so not 17.04 but still - this is a QT5 machine and not a QT4 so I think the experience will be similar.

I install libraries liblua5.1-0-dev, liblua50-dev , liblualib50-dev and libjpeg-turbo8-dev
I already have libpng12-0 and libpng12-dev
I also already had a working QT5 development set of tools installed so my starting point might be a bit easier than some.
But here is how my build worked.

I am building in ~/development

We need NASAs cspice .
Dowload the file cspice.tar.Z and importCSpice.csh from

in the directory where you saved these two files run the .csh script using the csh command shell and install cspice to to /development/cspice
/bin/csh -f importCSpice.csh

Now clone the git repository

cd ~/development
git clone
~/development/MyCelestiaBuild/celestia/ in a text editor
edit INCLUDEPATH and LIBS vars in in the unix{ section to point to where cspice was installed

ie change from
INCLUDEPATH += /DATA/NGT/cspice/include
LIBS += -ljpeg /DATA/NGT/cspice/lib/cspice.a

too (in my example)
INCLUDEPATH += ~/development/cspice/cspice/include
LIBS += -ljpeg ~/development/cspice/cspice/lib/cspice.a

Now try a build


qmake prefix=/usr ..

make -j4

sudo -s

make install

Binary is installed ~/development/MyCelestiaBuild/celestia/BUILD/celestia

execute by going to
cd ~/development/MyCelestiaBuild/celestia/BUILD
and running

Posted: 25.02.2018, 23:14
by John Van Vliet
I just updated the code last night so

my current git code uses png 16 , lua 5.1 ( a must use ) qt5 and gcc 4.8
it builds with a few warnings that i am working on .

Nowt it builds just fine using qmake ( qmake-qt5 )
just edit the *.pro to point to your cspice install and then add a " prefix" option to the build line

i use this ...

Code: Select all

cd  your / celestia / src / folder
 mkdir BUILD
qmake prefix=/DATA/SUSE/Qt5Celestia ..

make -j4
------ your root password ----
make install

then download the spice kernels and uncoment the lines in the ssc files to use the spice files
-- i still NEED to document this better

Posted: 26.02.2018, 00:02
by Janus
@John Van Vliet

There have been jobs where documenting everything was actually more work than the job itself.
Coherence and logic, easy.
Explaining ultrasonics transducer response speed for measurement to a metal worker, now that can be hard.

I have a devuan VM up and running, and I am trying to wrap my head around the whole compile in linux thing.
It is so different compared to what I actually know.

Would I actually offend anyone if I made a linux directory for linux libs in the celestia directory tree, the way there already is one for windows?

In my other work on windows, I maintain a separate copy of support libs for each project.
A few copies of Boost, Pantheios, stlsoft, lua, etc, is easy.
Yet under linux, I can't find anywhere to put anything.

The structure nearly forces you to work in your profile directory, yet I do not that in windows, I actively avoid it in fact.
I work based on drives and drive letters, to which so far, I can not find an equivalent in linux.

It is probably just me, and the way I work, but it is so frustrating.
Oh, that and I appear to have a choice between typing my password every few minutes, or have constant popups warning me that I am root.
This is in a VM that only connects to the internet when using the package manager, so what is the problem?
I would not use Linux in a production machine, if only because I still can not find anything, the underlying structure eludes me.

Were it not for the need to diversify my knowledgebase.
Made urgent by the (coming?) demise of Windows as an OS since M$ decided it is now nothing but a cloud account front end.
With ReactOS not ready yet, I am forced to adapt.
I would not bother with the headache, mentally tallying Linux as a wonderful OS for servers, which it really is.
For someone who thinks at the hardware level though, linux is so alien.

The kernel source makes a good read however, a little chaotic in places, convoluted in others, but overall well structured.
I can almost follow it most of the time, then I get lost.
It is a shame that it isolates the user from the hardware by design.
Given its job however, that is a necessity.
The problem here is that I refuse to let anything between me and what is mine, which it feels like it is doing.
I admit however, that my viewpoint from the hardware level likely colors my view.

Not meaning to ramble, just frustrated at the circles nearly everything about linux is defined in.

So, about that linux directory for support libs, would that work?


Posted: 26.02.2018, 12:24
by selden

There are more ways to organize software under Linux than there are different Linux distributions.

In many cases, where you work on a software package is determined by what you specify as your working directory (cd) before you start working on it. The master copy of the code is kept elsewhere, using cvs, svn or git. You can then check it out to whatever directory tree is convenient, which in turn can be located in whatever file system or partition that you want.

When installed on a running system, it again can go in whatever shared directory you want. Many "make install" commands assume a software package's directory trees will go under /usr/local, but some software management packages keep only softlinks there, which in turn point elsewhere, with different versions of a given package in separate directory trees. In too many cases software packages and their dependencies are all in rapid flux. (In a production environment, once a year could be considered too rapid due to all of the regression testing that has to be done to ensure compatibility.) In those cases, careful versioning is important and having several different versions of a particular software package installed on the same system is necessary in order to maintain compatibility for whatever software packages are being developed locally.

Posted: 26.02.2018, 16:31
by Janus

Thank you for the sane sounding reply, yesterday was not a good day.
My apologies to the universe, I should have known better than to reply to anything with how frustrated I was.
I am simply going through my by-annual try to wrap my head around linux without getting committed cycle.
And once again, I am losing, linux is getting away.

My problem is that I do everything by structure.
I also have my own way of seeing everything.
I work in snapshots of things.
While it makes it simple for me to debug, it is not large project friendly however.

What I want is something like how I organize my windows machine.
My boot drive, C:, has the OS, and nothing else.
I use custom install locations for everything.
Utilities on one drive, compilers on another, reference data on another, and so on.

I have multiple copies and versions of web browsers, all modified to use a local profile like the old netscape.
Every program I use is setup or modified to never use the windows profile directory tree.
There is literally nothing in my profile directory tree that I can put elsewhere.
Everything is self contained, or I do not use it.

Again, for me, the drive letters make a mental demarkation between physical storage devices.
I like them because cd.. can not take me from one to another.
I realize drive letters are something of an artifice, but it is a useful one to me.

I have studied the linux kernel mainly because I want find a way to make its internal file system present itself in a more friendly manner.
I am aware that it is just a presentation of an internal logic tree, I just want to tweak it.
I have this silly idea that computers are made to work for and adapt to us, so that is what I expect out of them.

What I actually want is drive letters because they make wonderful shorthand.
A single letter that maps mentally maps to a physical device or partition.
Even if I could find a way to get boot: for whatever it boots from, it would help.
Then drivelabel: for the rest, again, it would help.

My other gripe with linux, is there is no control about where things get installed.
I have no idea what something is called because program_name ~!= executable.
While I am convinced there is some logic to how everything is laid out / done in linux, that logic escapes me.

I have tried manually installing programs where I want them.
That part I can get done, then it is dependency h$77 as I try to figure out what it needs in order to run.
Which is annoying because it never seems to end.
I like everything small, simple, stand alone, it is much easier that way.

I do not use csv, svn, git, or any other program like that.
I work on snapshots, like the release or master zip files from github.
I normally have six or more copies of a source tree that I am experimenting with.
And I keep multiple versions of support libraries like boost etc as well.

I will keep trying, and likely fail yet again.
Then wait a while, and try again.
I am well aware that real problem is me, because I do not see or think like others.
I simply refuse to let that stop me.

Until then however, I am going back to brute force.
My current goal is to make compiling celestia with QT under linux, compile the support libraries first to create the libs it needs to link in.
Recompile everything at once seems to be the linux way, and should ensure that the support libs match the system being compiled on.
Since linux appears to have no end of desktops or distros, it seems easier to recompile that try to sync.

Make a /support_libs directory to put the support lib sources in.
Then make a whatever to compile them and copy the libs to /linux/lib, /linux/inc as needed.
I have been considering a similar structure for the windows versions.
If everything is compiled at once, then it is by definition, all in sync.

We'll see how much progress I make.


Posted: 26.02.2018, 18:08
by selden
One way to have something like single letter "drive names" would be to create single-letter directories in the root directory of the linux system disk and mount your physical drives on them.

mkdir /f

mount /dev/rz??/ /f

cd /f

Posted: 27.02.2018, 22:11
by John Van Vliet
i have tried to keep the build process as easy as possible
you are on a debian based OS ( the deb camp)
i use suse/Cent and scientificLinux ( the redhat rpm camp)

two very different types of package managers

for a debian system you use "apt search" and "apt-get" to lock for and then install software

on redhat yum ( or a like tool "dnf" and "zypper" ) is used

debain names the header files *.*-dev redhat uses *.*-devel

install the "build-essentials " deb package
the qt5 code kde plasma5 uses qt5 , but an older version will use qt4

qt4 and qt5 can both be installed - the only issue is the NAME of "qmake "
qmake ------ this might be a link to 4 or 5

if you are NOT installing to the default /usr location then you will NEED to add that location to the system $PATH
-- you run into this also on Windows , having to manually set a location in the system path

as to why everything is not all in one folder ( like Microsoft )
Linux FIXED THE ISSUE a very long tome ago as to NOT need to do that

a great bit of documentation - a bit old but GOOD
and about the file system ( Chap. #3 )

Posted: 27.02.2018, 23:17
by Janus
@John Van Vliet

Thank you for the links.
I actually have a print out that looks very much like this one.
It was included with a system that a customer gave me a few years ago, so I never knew where it came from.

They couldn't afford to actually pay me due to circumstances beyond their control.
Instead, they pushed their 'upgrade' cycle and asked me to handle recycling of their old server rack and desktop systems.
The printout was in a binder that came with the rack.

That print out was how I pieced together that the file system for linux is part of kernel space.
What I really want to accomplish is something like this.

Make a /drives directory.
Format the boot drive as CDRV, then mount it in /drives/C, here I just use C because it is familiar, no reason it couldn't be A, I've used A before.
Format my first storage drive as DDRV and mount in /drives/D
Follow through for the rest.

After that make a filter/program/mask or whatever it takes to map C: or D: over to /drives/C or /drives/D and hide the rest.
That way I would always know what hdd/drive/partition I am on by looking at the command line.
I am aware that would mean that /drives/C/etc would actually be /etc, but the isolation like that is what I need.
Sadly, what I want/need runs against the grain of how linux itself is structured and works.

Meanwhile the clock ticks on WIn7, the last windows version I will be able to use.
I have tried WIn8/8.1 with various addons and every tweak I can find, and they are junk in my eyes.
W10 is a travesty that makes no pretense that you own your own computer or data.
ReactOS is not yet ready to use everyday.

Therefore I study C/C++, file managers, graphic display programs, ReactOS itself, etc.
In linux I study the structure of X11, the Icewm window manager, and Wine.

If nothing else, I will eventually make my own shell with graphics for Linux.
I have a basic idea, but I lack the knowledge to implement it, though I am learning.

A: through Z: are just like lan: or http:, protocols.
The former point to drives, the latter to the network & internet.
I start with a file system and build from there.

A huge project, and one I have no idea how to accomplish yet.
But just as falling down is part of learning to walk.
I will fail and fail until I begin succeeding.

I am also aware that as I learn, my goal(s) will change, that is the nature of learning, and the growth that comes with it.


P.S. How does the compile the support libraries as part of the project sound to you?

Posted: 04.02.2019, 21:35
by Drumy9
Good Afternoon
I did can to install Celestia from Jhon Van Vliet on Debian 9 (Stretch), having installed qt5, lua, gcc, make and maths libraries before, with the next steps:
Download the last with:
◦ git clone
◦ Download the files cspice.tar.Z and importCSpice.csh from
◦ Copy this files on the folder /home/drumy/celestia (where I will use this program) and run the installation from a terminal open of this folder:
▪ /bin/csh -f importCSpice.csh
◦ Copy the folder MyCelestiaBuild on /home/drumy/celestia
◦ Open with mousepad the file en /home/drumy/celestia/MyCelestiaBuild/celestia and
▪ change the line
• isEmpty(PREFIX) { PREFIX =/DATA/SUSE/Qt5Celestia }
• isEmpty(PREFIX) { PREFIX =/home/drumy/celestia }
▪ change the line
• INCLUDEPATH += /DATA/NGT/cspice/include
• INCLUDEPATH += /home/drumy/celestia/cspice/include
▪ change the line
• LIBS += -ljpeg /DATA/NGT/cspice/lib/cspice.a
• LIBS += -ljpeg /home/drumy/celestia/cspice/lib/cspice.a
▪ Save the file and exit
◦ Now go to compile from a terminal open on /home/drumy/celestia/MyCelestiaBuild/celestia/BUILD:
▪ qmake prefix=/usr ..
▪ make -j4
▪ sudo -s
▪ make install
◦ Run from terminal open on directory /home/drumy/celestia/MyCelestiaBuild/celestia/BUILD with:
▪ ./celestia
My question is how to find a star when it isn't on the browsing menu from the left. I don't find on this Celestia a browser menu where I can introduce the astral objet that I want to study.
Thanks an avance for your answer.
P.D.: English isn't my first language, excuse me if my redaction is broke

Posted: 05.02.2019, 13:20
by Drumy9
I find the last night that I can find a stellar body with Ctrl+M.
I hope that my last post and this can help to somebody.

Posted: 05.02.2019, 18:28
by onetwothree
@Drumy9, I suggest using a main Celestia dev tree ( instead of outdated John's one.

Posted: 05.02.2019, 22:00
by John Van Vliet
i would not say " out of date"
but stripped of old unused code and using the legacy lua 5.1

it is a FORK of 1.70 that i use

as to finding a star
< control>+<m> or hit < enter> and start typing the name of the star

Posted: 07.02.2019, 17:56
by onetwothree
We have made some changes since the time you forked 1.7.0.

Posted: 13.02.2019, 01:53
by Anthony_B_Russo10
Another way of running Celestia in Linux is by using Wine allowing the use of the Windows version.
Example: 1.6.1 running

and 1.2.4

Posted: 16.02.2019, 14:04
by Drumy9
Hi. Thanks for your answers. I prefer don't use Wine because I don't like Windows. I prefer work all on Linux. The fork of John Van Vliet is working fine to me at this moment.
A huge

Posted: 16.02.2019, 21:51
by Anthony_B_Russo10
Ok it‘s just a suggestion since it as alternative to using the Linux version of Celestia on the main Celestia web page.