Building Celestia on Xubuntu Intrepid

[ajtribick]

I verify that using autoreconf -iv instead of make -f Makefile.cvs results in ./configure --with-gnome working.

Without applying the patches in my post upthread, this is the output after entering the "make" command.

Did it work with the patch and not editing admin/acinclude.m4.in after running autoreconf -iv?
cartrite

No. While using autoreconf -iv does get the ./configure --with-gnome to work, when I run make I get the libtool error described in my previous post.

The only way I've managed to get the GNOME version to compile is to edit admin/acinclude.m4.in and applying the patch, then using make -f Makefile.cvs

[cartrite]

That's strange. You would think that applying the patch and running autoreconf -iv would work?
Unless running "autoreconf -iv, ./configure --gnome, make" after applying the patch is producing bogus makefiles on your system.
You got me there.
You probably can't run "autoreconf -iv" for kde as well?
I do get a ton of warning messages when I run "autoreconf -iv".

./autoconf-test
autoreconf: Entering directory `.'
autoreconf: configure.in: not using Gettext
autoreconf: running: aclocal -I macros
acinclude.m4:42: warning: underquoted definition of KDE_PATH_X_DIRECT
run info '(automake)Extending aclocal'
or see http://sources.redhat.com/automake/auto ... ng-aclocal
acinclude.m4:169: warning: underquoted definition of AC_FIND_FILE
acinclude.m4:188: warning: underquoted definition of KDE_FIND_PATH
acinclude.m4:241: warning: underquoted definition of KDE_MOC_ERROR_MESSAGE
acinclude.m4:253: warning: underquoted definition of KDE_UIC_ERROR_MESSAGE
acinclude.m4:266: warning: underquoted definition of KDE_CHECK_UIC_FLAG
acinclude.m4:301: warning: underquoted definition of AC_PATH_QT_MOC_UIC
acinclude.m4:345: warning: underquoted definition of KDE_1_CHECK_PATHS
acinclude.m4:393: warning: underquoted definition of KDE_SET_PATHS
acinclude.m4:417: warning: underquoted definition of KDE_SET_DEFAULT_PATHS
acinclude.m4:494: warning: underquoted definition of KDE_CHECK_PATHS_FOR_COMPLET
ENESS
.
.
.
acinclude.m4:4519: warning: underquoted definition of KDE_COMPILER_REPO
acinclude.m4:4548: warning: underquoted definition of KDE_CHECK_HEADER
acinclude.m4:4559: warning: underquoted definition of KDE_CHECK_HEADERS
acinclude.m4:4571: warning: underquoted definition of KDE_FAST_CONFIGURE
acinclude.m4:4578: warning: underquoted definition of KDE_CONF_FILES
acinclude.m4:4593: warning: underquoted definition of KDE_SET_PREFIX
acinclude.m4:4676: warning: underquoted definition of KDE_LANG_CPLUSPLUS
acinclude.m4:4687: warning: underquoted definition of KDE_CHECK_LONG_LONG
acinclude.m4:4707: warning: underquoted definition of KDE_CHECK_LIB
acinclude.m4:4723: warning: underquoted definition of KDE_JAVA_PREFIX
acinclude.m4:4746: warning: underquoted definition of KDE_CHECK_JAVA_DIR
acinclude.m4:4951: warning: underquoted definition of KDE_NEED_FLEX
acinclude.m4:4963: warning: underquoted definition of AC_PATH_QTOPIA
acinclude.m4:5067: warning: underquoted definition of KDE_INIT_DOXYGEN
acinclude.m4:5104: warning: underquoted definition of AC_FIND_BZIP2
acinclude.m4:5189: warning: underquoted definition of KDE_CHECK_SSL
acinclude.m4:5374: warning: underquoted definition of KDE_CHECK_STRLCPY
autoreconf: running: /usr/bin/autoconf
autoreconf: running: /usr/bin/autoheader
autoreconf: running: automake --add-missing --copy --no-force
autoreconf: Leaving directory `.'

All the more reason to fix "admin/acinclude.m4.in".
cartrite

[t00fri]

Since Pat Suwalski is the local expert on gtk/gnome matters and subtleties of the autotools, it's probably best if he has a look at this. He has been seen on and off during recent times in the dev list...

Fridger

[ajtribick]

You probably can't run "autoreconf -iv" for kde as well?

If I do that, ./configure --with-kde fails to detect Qt3. Using make -f Makefile.cvs works fine.

[cartrite]

The ./configure I use in my scripts or on the command line in a terminal is a little more complicated that just --with-kde or --with-gnome. Here is a look at one of my build scripts.

Code: Select all

#!/bin/sh
cd celestia
autoreconf -iv
./configure --prefix=/home/cartrite/share/celestia/test --with-gnome --with-qt-dir=/usr/lib64/qt3 --with-qt-libraries=/usr/lib64/qt3/lib64 --enable-libsuffix=64 --with-lua --with-cspice-dir=/home/cartrite/share/cspice/cspice
make
make install


This is what I ran to test the patch with gnome. I've been using a variant of the configure line ever since I started using a 64 bit OS.
cartrite

[ajtribick]

Ok, got it to work with

Code: Select all

./configure --with-kde --with-qt-libraries=/usr/share/qt3/lib --with-qt-dir=/usr/share/qt3 --enable-libsuffix=64 --with-lua --with-cspice-dir=/usr/local/cspice

However make fails with the libtool problem I described earlier.

[ajtribick]

Meanwhile, the qt4 version can be fairly simply compiled: apply the patch, then...

Code: Select all

touch config.h
cd src
qmake celestia.pro

Then edit Makefile, adding "-I/usr/include/lua5.1" (minus quotes) to the end of the variable INCPATH, and changing -llua to -llua5.1 in the variable LIBS. Save, then

Code: Select all

make

And everything's fine.

(This assumes you've got cspice installed in /usr/local/cspice, otherwise further edits are necessary in the Makefile)

[t00fri]

Meanwhile, the qt4 version can be fairly simply compiled: apply the patch, then...

Code: Select all

touch config.h
cd src
qmake celestia.pro

Then edit Makefile, adding "-I/usr/include/lua5.1" (minus quotes) to the end of the variable INCPATH, and changing -llua to -llua5.1 in the variable LIBS. Save, then

Code: Select all

make

And everything's fine.

(This assumes you've got cspice installed in /usr/local/cspice, otherwise further edits are necessary in the Makefile)

Yes, but what's new here? I do it this way since months...It always works fine.
Except that I wrote my personal *.pro file that sets the dirs and Linux optimizations as I prefer them ...

Fridger

[cartrite]

However make fails with the libtool problem I described earlier.

I have a similar problem when I try to build gdal. I have to use --without-libtool. When I use ./configure --help with gdal, the --without-libtool is given as an option. Celestia's ./configure --help does not give the --without-libtool option. It does have --without-PACKAGE so I tried to put it in my configure command but it looked as it was ignored.

This is getting kind of scary. If someone starts fiddling around with libtool, who knows what problems that will cause. I already can't use it when I build gdal.
cartrite

[John Van Vliet]

--- edit ---

[ajtribick]

John Van Vliet, thanks for the explanation. The part about string #includes is also supported by openSUSE's GCC 4.3 Transition page.

[t00fri]

John Van Vliet, thanks for the explanation. The part about string #includes is also supported by openSUSE's GCC 4.3 Transition page.

Yes that makes sense. But it might also mean plenty of fiddling to get rid of new warnings and errors.

Right now I am literally walking on my nerves, because of the frustration due to the wealth of incompatible Linux flavours and versions thereof! If one wants to distribute these days binary distributions for Linux, this incompatible diversity turns into a nightmare.
Just imagine that the binary CUDA code is presently offered for as much as 11 Linux flavors for 32bit and 64bit each. This development is absolutely crazy!

Since quite a while cartrite and I try to become "binary compatible" in the context of my F-TexTools-2.0prex and Nmtools-2.0prex releases. This seems virtually impossible, although he and I use the same Linux flavor (OpenSuSE) and in the versions only differ like 10.2 and 10.3!

NOthing goes anymore between 10.2 and 10.3!

+++++++++++++++
We undergo this frustrating work ONLY because it is said to be too much for the average user to compile things from sources...
++++++++++++++

In contrast, under Windows XP there is no problem whatsoever. There is just one "flavour" of it since many years.

Fridger

[John Van Vliet]

--- edit ---