Celestia Forums

Hi,

For some time now there seem to be some problems in the building (or installing) system in CVS.

1. Under Debian Linux, the lua-includes are located in /usr/inlcude/lua50, but even when giving the correct paths to configure (--with-lua-inc/libdir...) I have to patch some source files to include <lua50/lua.h> instead of <lua.h> and <lua50/liblua.h> instead of <liblua.h> to make it work

2. configure complains about missing QT 3.3, but after changing the configure script, celestia builds with QT 3.2 too. Is QT 3.3 REALLY needed? Please consider to keep a minimum of backward compatibility.

3. After making the KDE version successfully and after a "make install" I can run celestia, but the menu looks very strange:


Note that this strange menu appeared sometime after the 1.3.2 release and BEVORE the change to QT 3.3 so I don't think my personal hack to make celestia build is the reason for this.

Thanks for any help,
steffens


System:
- Debian Woody
- KDE 3.2.2
- Kernel 2.4.27
- gcc 2.95.4

steffens wrote:Hi,

For some time now there seem to be some problems in the building (or installing) system in CVS.

I have no problems whatsoever with CVS and SuSE.
It's all a matter of making some trivial adaptations here and there...

1. Under Debian Linux, the lua-includes are located in /usr/inlcude/lua50, but even when giving the correct paths to configure (--with-lua-inc/libdir...) I have to patch some source files to include <lua50/lua.h> instead of <lua.h> and <lua50/liblua.h> instead of <liblua.h> to make it work

This is one example. The lua libs compile in seconds. So why don't you make a new .deb archive from the sources by just modifying the lua header install directory as needed in Celestia. Another even simpler option would be to use symbolic links in /usr/include like


etc. That works for me and takes much less time than describing your problem above...

2. configure complains about missing QT 3.3, but after changing the configure script, celestia builds with QT 3.2 too. Is QT 3.3 REALLY needed? Please consider to keep a minimum of backward compatibility.

It is virtually impossible to maintain too much backward compatibility in CVS largely due to the persistent problems one encounters with the 'autotools', i.e. automake & autoconf etc in such cases. What presently sets the limits in CVS is the version 2.5.7 of autoconf. I had no problems to compile the code for KDE 3.3.x and 3.2.x which covers quite some time back. The QT distribution then must vary accordingly.

3. After making the KDE version successfully and after a "make install" I can run celestia, but the menu looks very strange:
...

I never encountered anything like that;-)

Bye Fridger

I'm so glad I got involved in Celestia.
Seeing the endless hassle that Linux users seem to have over every little thing they do makes me much more serene about Windows!

Does anyone else get that, or is it just me?

Grant

PS: Sorry, steffens ... no intention to belittle your current problem. I've just seen so much of this stuff go past that I finally found myself unable to suppress the urge to comment.

granthutchison wrote::)
I'm so glad I got involved in Celestia.
Seeing the endless hassle that Linux users seem to have over every little thing they do makes me much more serene about Windows!

Does anyone else get that, or is it just me?

Grant

PS: Sorry, steffens ... no intention to belittle your current problem. I've just seen so much of this stuff go past that I finally found myself unable to suppress the urge to comment.

I wholeheartedly agree with you and even wrote on and off in my anger to Christophe that Linux is definitely on its way down the drain...

As I often emphasized, the problematic is almost unrelated to Linux itself, but rather to the fierce fight for commercial dominance and survival of the ever increasing lot of Linux distributors. In order to make (less experienced) users increasingly dependent on their specific Linux distribution, it is evil tactics to patch every program extensively, and the Linux kernel even tends to come with as many a hundred (!) patches.

A most unpleasant and direct consequence is the never ending hassle with the UNIX autotools. The endless discussions and problems you will surely recall from our developer site...Also, programs cease to be interchangeable among different distributions.

Another cause of big trouble is the much increasing dependence of application programs on specific desktop schemes (i.e. a host of different GUI libraries). For me it is pure horror. This used to be the worst conceivable thing to do in UNIX!

But times are changing and meanwhile, I am using Windows XP a lot besides Linux...


Bye Fridger

granthutchison wrote::)
I'm so glad I got involved in Celestia.
Seeing the endless hassle that Linux users seem to have over every little thing they do makes me much more serene about Windows!

Does anyone else get that, or is it just me?

If I may interject a thought here...

Windows is no bed of roses either. The latest Service Pack has
managed to cause its own share of curious new problems.

The only reason Windows has fewer such problems, however, is because
of its widespread use. Software developers simply have to get it
right before it hits the shelves, or they are run out of business.

Seems to me that Linux Users don't get the same amount of support from
developers, perhaps because:

A. They're generally more intelligent than the average Windows user.
B. They're more readily able to fix their own problems, and
C. they are generally stuck with the software because they need it for work.

Just my opinion, of course.

Take care, Bob

Grant, you must also remember that we're talking here about compiling the CVS version. Problems with compiling the CVS version under Windows are quite common here too.

Problems people encounter under Linux usualy arise from the fact that they try to install packages made for another distribution or another version of their distribution (plus for whatever reason SUSE just can't get it right).

Now Steffens, to your problems:
1 - ./configure --help
-> use --with-lua-includes and --with-lua-libs

2 - You're right, Qt 3.3 isn't required, but we sync'ed the build system with KDE CVS recently and that's probably what introduced that requirement. I'll try and correct this.

3 - Remove ~/.kde/share/apps/celestia/celestiaui.rc
This problem seems to appear if you upgrade and you have a personalized toolbar (I probably should have bumped the version number of the rc file).

Christophe wrote:Grant, you must also remember that we're talking here about compiling the CVS version. Problems with compiling the CVS version under Windows are quite common here too.

Yes, I know. It wasn't quite the right thread to make the comment on: but the comment is nonetheless heartfelt.

Grant

I had trouble with cvs days ago.

Maybe because of massive changes. Anyway, after this two commands, everything worked ok

make clean
make -f Makefile.cvs

and as usual:

./configure --with-kde etc etc
make

Christophe wrote:Now Steffens, to your problems:
1 - ./configure --help
-> use --with-lua-includes and --with-lua-libs

That's almost what I did, but SORRY, I used --with-lua-include (missed the 's' at the end!) I will try it again. Not a major problem anyway since this was easy to fix...

Christophe wrote:2 - You're right, Qt 3.3 isn't required, but we sync'ed the build system with KDE CVS recently and that's probably what introduced that requirement. I'll try and correct this.

This would be great. I know that keeping backward compatibility can be a lot of extra effort, but in this case... If QT 3.3 is not needed, why require it? This is one of the things that make life difficult on linux

Christophe wrote:3 - Remove ~/.kde/share/apps/celestia/celestiaui.rc
This problem seems to appear if you upgrade and you have a personalized toolbar (I probably should have bumped the version number of the rc file).

I have no such file, and creating it (using the file from cvs) does not change anything. I had strange menu behavior before when installing to /usr/local since in Debian KDE will only search in /usr. But I had no such problems for a long time since I used --prefix=/usr. I don't know what might have changed.

steffens

t00fri wrote:The lua libs compile in seconds. So why don't you make a new .deb archive from the sources by just modifying the lua header install directory as needed in Celestia.

You don't want to suggest to an average linux user to repackage a standard (in the meaning of "distribution") package just to compile some software? First of all, that's not needed (that's what the configure-options are there for) and second - there's more about .deb packages than simply some files and locations. Quite a lot of care has to be taken not to break the dependency system, the possibility to upgrade and so on.

Anyway, once again sorry for wasting your time on that lua topic as this seems to be my fault (see previous post).

steffens

steffens wrote:

t00fri wrote:The lua libs compile in seconds. So why don't you make a new .deb archive from the sources by just modifying the lua header install directory as needed in Celestia.

You don't want to suggest to an average linux user to repackage a standard (in the meaning of "distribution") package just to compile some software? First of all, that's not needed (that's what the configure-options are there for) and second - there's more about .deb packages than simply some files and locations. Quite a lot of care has to be taken not to break the dependency system, the possibility to upgrade and so on.

Anyway, once again sorry for wasting your time on that lua topic as this seems to be my fault (see previous post).

steffens

Are you trying to suggest that one or all of the many existing Linux distributions represents some kind of UNIX "standard"?;-). Every distribution puts the LUA headers somewhere else. So....

This would mean that for Celestia we produce about 10 slightly different source code packages and a similar number of binary ones? To satisfy all "standards" in existence. Absurd. Since people do not tend to read ./configure --help either, we are screwed. Right?

What I was trying to tell you instead is to make a slight modification to your installation, such that Celestia will be happy. Any Debian program that might need LUA will continue to find it.

Well well... I have set up my own Linux "distro" already in 1990 when nothing but Slackware existed. Things were much easier at that time. No patches. Just the original tar balls.

So I still have no hesitations today to modify and recompile things if I consider it practical.

I do not see why you can't delete the "official" Lua package in Debian ( since it's outdated anyway;-). 5.02 was the current one this summer...). Incidentally, as you can see...my philosophy works excellently. I never had any problems whatsoever with CVS, except if someone introduces a bug...

Anyway, without danger, you can install your own LUA package below /usr/local. That's what /usr/local is made for. I am sure also in Debian;-))

UNIX is a most transparent structure. It was so before Debian and it still is;-)

Bye Fridger

steffens wrote:

Christophe wrote:3 - Remove ~/.kde/share/apps/celestia/celestiaui.rc
This problem seems to appear if you upgrade and you have a personalized toolbar (I probably should have bumped the version number of the rc file).

I have no such file, and creating it (using the file from cvs) does not change anything. I had strange menu behavior before when installing to /usr/local since in Debian KDE will only search in /usr. But I had no such problems for a long time since I used --prefix=/usr. I don't know what might have changed.

Yes, that's strange.

Under KDE menus and toolbars are created dynamically at run time from an XML file (a .rc file). Check that /usr/share/apps/celestia/celestiaui.rc is present on your system, and if not copy it from your cvs sandbox src/celestia/kde/data/celestiaui.rc.

Something that changed recently in CVS too is that now all versions of celestia (kde, gtk, etc.) use $prefix/share/celestia as data directory, and $prefix/share/apps/celestia (used by KDE for things like .rc files) is a symbolic link to $prefix/share/celestia. So you should check that /usr/share/apps/celestia is correctly set up as a link to /usr/share/celestia.

Now, when installing celestia, or any other KDE app, in /usr/local, you must remember to set $KDEDIRS to /usr:/usr/local otherwise your app won't be able to find some of its data files. (see http://wiki.kdenews.org/tiki-index.php?page=Environment+Variables)

Hi,

I now have checked building with correct configure options --with-lua-includes and --with-lua-libs, but lua.h is still not found in some places. No big problem for me, but not very nice...

I really don't know what's the problem with my strange menu. Everything is installed under /usr/share/celestia. I checked the symlink and everything seems fine. The .rc file is in place.
When I get the time I will try to uninstall everything related to celestia, install again from scratch, check permissions...

Thanks anyway to the people that do the hard work to support celestia on linux. Show the windows users that it's possible

steffens

steffens wrote:I really don't know what's the problem with my strange menu. Everything is installed under /usr/share/celestia. I checked the symlink and everything seems fine. The .rc file is in place.
When I get the time I will try to uninstall everything related to celestia, install again from scratch, check permissions...

Something you can try is launching celestia with strace (traces system calls) :


it will show which celestiaui.rc its trying to open and if it fails the reason why it fails.

Christophe wrote:Something you can try is launching celestia with strace (traces system calls) :

Code: Select all

strace -e open celestia 2>&1 1>/dev/null | grep celestiaui.rc

it will show which celestiaui.rc its trying to open and if it fails the reason why it fails.

Now that's strange! It does not try to open any celestiaui.rc at all !?! At least there is no mentioning of this file in the trace. Everything else seems ok, there is nothing that I would spot as an error message. I can post the full strace output, if it would be of any help. What more info can I provide?

steffens

try

strace -f celestia 2>&1|fgrep celestiaui

EDIT: for me that shows

[pid 11097] stat64("/home/hjw/.kde/share/apps/celestiaui.rc", 0xbfffd20c) = -1 ENOENT (No such file or directory)
[pid 11097] stat64("/etc/opt/kde3/share/apps/celestiaui.rc", 0xbfffd20c) = -1 ENOENT (No such file or directory)
[pid 11097] stat64("/opt/kde3/share/apps/celestiaui.rc", 0xbfffd20c) = -1 ENOENT (No such file or directory)
[pid 11097] stat64("/home/hjw/.kde/share/apps/celestia/celestiaui.rc", {st_mode=S_IFREG|0644, st_size=4236, ...}) = 0
[pid 11097] stat64("/etc/opt/kde3/share/apps/celestia/celestiaui.rc", 0xbfffd05c) = -1 ENOENT (No such file or directory)
[pid 11097] stat64("/opt/kde3/share/apps/celestia/celestiaui.rc", 0xbfffd05c) = -1 ENOENT (No such file or directory)
[pid 11097] open("/home/hjw/.kde/share/apps/celestia/celestiaui.rc", O_RDONLY|O_LARGEFILE) = 13

It takes "/home/hjw/.kde/share/apps/celestia/celestiaui.rc"

hjw

Yes, -f is required since the process is forked (sorry, I couldn't test the trace command at work).

Here's what I get:

Here is what I get:


This is after completely removing everything related to celestia on my system and a fresh install from cvs sources. The file is existing and readable. Still I get the same strange menu as described before.
Do I understand correctly that the file is opened twice? This might at least explain the doubled entries???

steffens

Hi,

for everyone interested: the problem is resolved for me now.

The problem was that celestia did not find ui_standards.rc.
On Debian, the main kde config dir is /etc/kde3, the standard dir is KDEPREFIX/share/config. Maybe on the Woody-Backport of KDE there was a patch missing to search in /etc/kde3.
did help.

steffens