Celestia Forums

Hi, for the most part I really like this program, it works great.
I am trying to compile Celestia on win32 (XP) with Mingw. No Vista, or 7 ever.
I am also only learning C/C++ languages, I do not know them well.
I can not use VS anything as it conflicts with other software I use.
I have the same type though fewer issues with the platform sdk ddk stuff.
VS also does not work properly in virtualbox so that is not a real option for me.
I do not know cygwin or mingw very well.
I am not and never will be a mac user, the way things are done runs counter to the way I think.
Those that like them please enjoy, just know that I will never be among you.
I am trying to learn Linux, but the logic so far escapes me.
I have tried ubuntu and fedora, both confuse me, the latest gnome is completely incomprehensible to me.

I did a clean install of the latest mingw and have spent a week so far figuring out which libraries are needed, and copying them from cygwin.
I tried looking through the configure script and makefiles to see what was happening and what is needed.
I've seen less complicated database setups that were more sensical.

So, is there a list of required libraries needed to compile Celestia?
My intent is once I get Mingw (w/Msys) working, I will upload a copy of it and the source to my site as a kind training wheels for those wishing to play.
That way if you glitch badly, just re extract and start over.
Unlike cygwin which uses the registry, mingw being a standalone program means you can have multiple copies of it on your system.

After dealing with some type redefinition errors I am currently down to some weird stuff.

undefined reference to __CRT_MT

I am hoping someone here will have a clue.

Thank you.

This is certainly something I want to have working. I already have a qmake file that will do this, just need to finalise some other things first. Stay tuned...

--- edit ---

john Van Vliet wrote:

I did a clean install of the latest mingw and have spent a week so far figuring out which libraries are needed, and copying them from cygwin.

copping them from cygwin will cause problems

the two are similar BUT VERY VERY VERY different

MinGW builds windows *.dll's and *.exe using the dlltool to turn the Mingw .la & .so 's & .def's into *.dll's

on xp you probably want to use the GnuWin32 programs or build EVERYTHING from source

the mingw headers are VERY DIFFERENT than the cygwin headers the two ARE NOT interchangeable

also you need to keep the Microsoft Windows headers AWAY from Mingw !!!!!!!
DO NOT let mingw see the windows source headers !!!!

I would RENAME the Visual studio install folder BEFORE doing anything in mingw
then RENAME the mingw install folder before launching VS
install mingw to
C\\: GnuWin32/MinGW
C\\: GnuWin32/ Msys

but i think you will find that the source will build better on the free Microsoft compiler
than in MinGW gcc 4.1 and/or in Bloodshed's "Dev-c++ " GUI

First and foremost, I AM NOT, and WILL NOT be using VS, I hate it.
It wrecks a number of little things in my system setup and is incompatible with a number of my programs.
I have a lone copy I keep in a Vbox install, but isolated from my system, I spawn copies per project then delete them.
I also keep fedora in a Vbox, actually several, mostly for learning cross compiling with linux/gcc/cygwin.

Since you know far more than I do about gcc/mingw etc, I have a question.
Is there a sane and coherent guide anywhere to the whole build/configure/make process?
The ones I have been able to find apparently assume you have some sort of secret mental handshake to know what they mean.
I know much of the limitation is me, I am completely self taught.
I work at a low level, and much of modern programming is high level.
I try to look up what is to my eyes tools named by shorthand, and find explanations written in more shorthand.
I try to follow it, and I end up going in circles, without a single solid definition in the loop.

I think in more of an assembly or basic level, pascal is high level for me.
Bios or dos calls to 'print' or 'print string' are easy. int10 Fn13 with es:bp or Int21 Fn09 with ds:dx (x86 only here, others very different.)
print in basic is simplistic, but predictable.
write or writeln from pascal make sense.
cout<<"wft? over."
looks like a bit shift to me.
printf breaks up text and data so the eye can't follow the flow easily.
I am still trying to understand why people like C/C++.
And what is the difference between an object and a class anyway?

Enough ranting though, my problems, not anyone elses.
Is there a way to trace where a type is declared in C?
Is there a way to trace where a variable is declared in C?
Is there a way to trace where a procedure/function is declared in C?
Is there a tool to trace dependencies?
Is there a tool to trace includes?
Is there a coherent list of environmental variables used by the compile process so I can trace compile time by hand to figure out which lines are actually used and which are if elseif'd around?
I keep having to use ztree, a win32 copy of xtree, to search whole source trees to find declarations, and it is slow.

Just looking for a place to start.

Doors.

--- edit ---

john Van Vliet wrote:

First and foremost, I AM NOT, and WILL NOT be using VS, I hate it.

MinGW dose build for the Microsoft C runtime

it has been some time since i used Microsoft ( except for a few times, i do have a bootleg copy of 7 )
i went windows free in 2005

as for a mingw guide
most of the old linux terminal guides will do
http://tldp.org/LDP/Bash-Beginners-Guid ... index.html
there is no real DE gui for mingw
you can get a OLD version of xfree86 to run and there is a emacs xfree86 port
( emacs can be used to call gcc just like in any Linux distro)

or bloodsheds " Dev-C++ " for a gui
http://www.bloodshed.net/devcpp.html

Thank you for the reply.
However, I am not looking for an IDE for mingw.
I am however looking for a coherent list of libraries needed to compile celestia.

I do not have the secret hand shake or whatever it is it takes to use the guides out there.
I do not grock your head space.

You state that you went MS free on 2005, wonderful, good for you.
I am waiting on Reactos to go beta before I make the same jump.

I have a lot of trouble with Linux in general.
The logic the unix/linux layout is a vast puzzle for me, mac's are even worse.
I am a storage oriented person, and I have found nothing in unix/linux or mac's that is solid, so I am lost.
I have even more trouble with the whole build compile system of gcc/cygwin/ whatever all there is out there.

I have looked at the guides you mentioned and they are part of what confused me.
Since you are a long time user I don't think you understand how confusing most of it is for new comers.
No foundation is present, no starting point is given, no constants defined.

I have no doubt there is solid logic behind it all, I simply can't see it.
My mind doesn't work that way.
Phrases like 'stateless comparator statement for two or more values' mean absolutely nothing to me.
Everything has a beginning or foundation, a middle or content, and an ending or finished product.
I am looking for the beginning, the foundation.

More than one place has called make files black magic, and given how they are presented, I can see why.

I am accustomed to using a bare compiler with minimum of libraries installed.
The most complicated IDE I like is the old turbo pascal or newer free pascal one.
I don't do visual languages.

I know enough to run the configure script.
Where does it get its information?
Where does it come from?
Is it written in M4?
If so, what is M4?

Sorry, not meaning to rant an anyone.
I am just frustrated because I can't seem to find anything coherent anywhere.
The ones that look coherent end up referring back to themselves in circles of varying sizes.
The only other project I messed with included mingw support directly in the source tree.

I know there is logic, I am just looking for it.

Doors.

--- edit ---

john Van Vliet wrote:the first thing is to get MinGW set up AND working 100%
that will take time
-- going over your first post

Unlike cygwin which uses the registry, mingw being a standalone program means you can have multiple copies of it on your system.

well you DO need to add locations to the windows $PATH
and that IS in the windows reg.

My understanding is that gtk is Linux only, but then I could easily be wrong, gui's are NOT! something I program.
Been wrong before, I'm used to it, I learn better and go on.
My aim is to build celestia --with-glut --with-lua
I will certainly give building gimp a try, I could use the practice despite having no use for the program.
I have used a portable version before, worked fine, but graphics are not my thing.

I got
GLUT : eventually anyway
libpng, I think it was 14; libpng14 ( not 12 or 13 -aka12b)
LUA : This one is hard, unable to accomplish.
ffmpeg : I don't understand, I looked it up and it appears to be video codecs. I only use xvid.

Lua is my big hang up.
The rest I have been able to work my way around, or make work.
Lua has eluded me.


The only way Mingw needs to be in the main path, via the registry, is if I want it there always, which I don't.
I use bat files with shortcuts to msys in order to prepend local path and other variables on launch.
I utterly and completely despise needing to use the registry.
I don't think any better of user profiles, but I do understand that others need/want them.
My main path contains no garbage or unnecessary stuff, my install is threadbare and simple.
I have dumped programs, quit using them, simply because they wouldn't run without the install directory in the path.
That is one my issues with VS, it HAS! to be in the path always in order to use it at all.
The %#$ thing intercepts a bunch explorer stuff, altering how I am allowed to view my own drives.

--- edit ---

john Van Vliet wrote:

My understanding is that gtk is Linux only

that is 100% wrong

GTK is made for ALL os's
and there are a BUNCH of Microsoft Windows programs that use GTK

My aim is to build celestia --with-glut --with-lua

use GTK

glut is deprecated

also the gtk version will be going by-by in favor of QT

using Microsoft "bat" files in mingw is not that good of an idea

use the linux shell in mingw
it is one of the BASH derivatives
put "C:/GnuWin32/Mingw/bin" and C:/GnuWin32/Msys/bin in the windows system path
and add C://GnuWin32/MinGW/lib to the Microsoft system library path

also be warned
there can be NO blank spaces in folder names
if so you need to call it from the old fat16 type name
"Program Files" = "prog`1"

In researching it after you mentioned I have found I was indeed wrong.
I was unaware of how many programs use it.
While my familiarity with glut is limited, I at least know it.
I am attempting to learn opengl and wish to limit the number of new things I am taking at one time.
I will study GTK later, post getting a working mingw, etc.

I believe that windows has changed somewhat since you quit using it.
The bat files I use are the ones that come with msys.
Perhaps I wasn't explicit enough, but I DO NOT WANT! the compiler in the main path.
I keep my core windows install as small as I can.
I DO NOT have VS installed or the SDK, so there is no microsoft library path.

I am aware of the no blanks or spaces in the folder names rule.
Apparently in Linux there is little distinction between OS and compiler.
I use NUMEROUS compilers, compiling systems, linkers, etc.
If I put one compiler in main path then I can end up with an x86 tool called when I am working on a Mips or Arm or H8 or 803x or 804x or 805x or 86xx or 68xxx or 65xx or 65xxx or ladder programming. (The latter is one form, among many, of PLC or embedded controller programming.)
Or worse, a C/C++ compiler command when I am doing assembly or basic or pascal programming.
I am new to C/C++/Linux/Gcc/Mingw/ Etc, not programming.

I will get to X, Gnome, Windows Etc as I can.
I also have many tools I have written myself with names that sometimes conflict.

Part of my goal in learning to compile and program for Celestia is to make a custom version on a flash card I can plug into a multimedia picture frame running Linux that will show real pictures from space generated in real time using something like a Kinect as a motion controller so the display changes in response to people walking by or standing and talking while watching it.

I am trying to leverage what I already know to learn more.
To me the idea of putting a single compiler in the main path of the OS is the height of stupidity from simplicity, ease of use and a security standpoint.
However, your needs are not mine, and mine are not yours.
What is silly or stupid for me, may be exactly what you need if that is the way you work.

Once I get a working mingw setup, I am going to put it on my site as a starting point for others like me who are just learning.
Sometimes people just want something that works so they can watch the process.
It is hard to go through the dozens of steps blindly typing cryptic unexplained command lines that are of all things, caSE senSitive.
Since that is what I need in order to get started, I am going to try to save someone else like the headache.
That way they can play with it, and if they break something, just reextract the archive.
It also provides a template for learning.
If an attempted install fails, compare what you ended up with to a working one.

I tried to use the gunwin32 stuff, but all it gave me was a bunch binaries after a full install, with no way to do anything with it.

Thanks for the effort.

Doors.

--- edit ---

john Van Vliet wrote:oh you are talking about that bat that launches rxvt terminal
i thought you were meaning the "makerelease.bat" and in general using bat files to run the commands

your first step is to get mingw configured and have a "hello world" program build

edit all the *.pc files in /lib/pkgconfig folder and have them point to the right location
edit all the text files in /mingw/bin to point to the correct location
and edit the
/msys/etc/bashrc ( i think it is called that ) to set the mingw system variables and mingw system $PATH

that way from rxvt ( or cmd.exe) you can set default shortcuts
like the mingw/bin as
/bin

or your build directory ( i recommend )
//c/mingw/src and in rxvt be able to use just

Code: Select all

cd /src
instead of the full path
cd C://GnuWin32/MinGW/src


When I launch it, the search paths for mingw are prepended for use in a window in mingw format. '//c/mingw' or some such.
Unfortunately the default Mingw install sets things up complicated.
Msys actually goes in a subdirectory, then my profile name goes under home under msys under mingw (I hate user profiles, but that is just me.)
/mingw/msys/home/profile
So what I did was move msys back to root, /msys/bin to /bin and the rest, then remove the msys/bin etc from the paths and scripts.
I also reset the update script path to reflect this.
I am trying to figure out how to set the profile name in the command line.
I am not having any success yet, but I am trying.

My install, default run install all packages, doesn't have /lib/pkgconfig dir.
I eliminated the /mingw directory.
/ on the prompt is actually my base directory 'c:\mingw' for me.
I hadn't realized how many files that look like programs are actually shell scripts.
The fact that there is no way to tell scripts from programs in this kind of environment bothers me.
I have seen problems from that, windows has been known to launch a file based on signature not extension, and that causes a lot of problems.
Windows has lots of stuff that drives me nuts.
I use an extension to explorer (not IE, windows explorer), that gives a file extension column, not a file associated with column.
Anyway, I am looking for file and scripts that effect paths and checking them one by one.

Since you know the compiler, are there any tools that will trace dependencies and includes?
I am looking for a way to get a list of variables, types etc, and where they are defined.
I have my own, but they don't handle C/C++ source files.

Doors.

--- edit ---

I would strongly recommend building using the Qt interface, as this is the way we are going in the future for the Celestia 1.7.0 release. The other interfaces are no longer supported.

I have recently compiled the relevant libraries and updated the celestia.pro project file to enable building with MinGW. I've posted details of how to update the source code on the developers' mailing list, go here for details.

Personally I usually use MSVC2010 on Windows and am less experienced with MinGW, so results from your testing of this would be very useful!

ajtribick wrote:I would strongly recommend building using the Qt interface, as this is the way we are going in the future for the Celestia 1.7.0 release. The other interfaces are no longer supported.

I have recently compiled the relevant libraries and updated the celestia.pro project file to enable building with MinGW. I've posted details of how to update the source code on the developers' mailing list, go here for details.

Personally I usually use MSVC2010 on Windows and am less experienced with MinGW, so results from your testing of this would be very useful!

Thank you for the link and mingw updates.
Without them I would have been a lot longer making sense of all this.

There is a problem with the SVN(5205) and the released SRC(1.6.1) for celestia.
The SVN does not contain a configure script.
The SRC does not contain pro files mentioned in the diff found on your link.

I found the following files missing from the svn as well.
aclocal .m4 133,418 .a..
celestia .mak 18,509 .a..
config.h .in 6,437 .a..
configure 970,392 .a..
makedebug .bat 88 .a..
Makefile .in 35,746 .a..
makerelease .bat 92 .a..
subdirs 83 .a..

If needed I can send what I have as I have it if needed.
Hopefully someone who actually knows all this stuff can fix it.

Doors.

ajtribick wrote:I would strongly recommend building using the Qt interface, as this is the way we are going in the future for the Celestia 1.7.0 release. The other interfaces are no longer supported.

Personally I usually use MSVC2010 on Windows and am less experienced with MinGW, so results from your testing of this would be very useful!

After all the other stuff is fixed.
How do I enable the QT interface?
When I run the configure script in the SRC(1.6.1) I get only four options.

$ ./configure
configure: error: You must select an interface to build.
Possible options are:
--with-glut GLUT front-end
--with-gtk Enhanced GTK GUI
--with-gnome GTK GUI with Gnome features
--with-kde Enhanced KDE GUI

Whether this is tied to the other issues is beyond my current skill level.

Doors.

Ah you are compiling v1.6.1?

Probably best if you are compiling from source on Windows to build the trunk, the 1.6.x code was branched off a long time ago. MinGW is not supported on 1.6.x.

ajtribick wrote:Ah you are compiling v1.6.1?

Probably best if you are compiling from source on Windows to build the trunk, the 1.6.x code was branched off a long time ago. MinGW is not supported on 1.6.x.

I have tried 1.6.1 and the current trunk.

As I mentioned previously, the first problem I ran into with the trunk was a missing configure script.

I tried downloading the HUGE, QT development package, then tried to compile the SVN truck through QT creator.
Gave me a errors, missing windows.h, declared unused stuff, and kept defaulting to VS instead of Mingw which installed as part of it.

If I have to keep using it I am putting it into a Vbox, that thing is as ugly and bloated as VS or Delphi.
It also tried to put itself into my main path, ahead of the windows directory.

Since you know QT, is there a place to get it as a single DLL that doesn't require the cygwin, mingw or other dlls?
I want to try it out with freepascal (NOT!! Lazuras), and the one I found requires a bunch of support dlls.
ALternatively, how do I compile QT into a single (Even if huge), DLL I can use with freepascal or something else.
Also, mingw DLL? What the heck, I thought the point of mingw was not to need translation dlls.

Doors.

You need to run "autoreconf -ivf" as the first step of the build process, as described here.

While the Qt SDK supports MinGW I do not believe it provides support for compiling under MSYS. I guess you'd probably have to compile Qt from source to do that. I'm not using MSYS for my own MinGW builds.

Easiest way to build trunk with MinGW is to use the celestia.pro file in the src directory, after applying the patch I linked earlier. (Note this is not under MSYS)

cd src
qmake -spec win32-g++ celestia.pro
mingw32-make release

ajtribick wrote:I would strongly recommend building using the Qt interface, as this is the way we are going in the future for the Celestia 1.7.0 release. The other interfaces are no longer supported.

I have recently compiled the relevant libraries and updated the celestia.pro project file to enable building with MinGW. I've posted details of how to update the source code on the developers' mailing list, go here for details.

Personally I usually use MSVC2010 on Windows and am less experienced with MinGW, so results from your testing of this would be very useful!

Tried QT creator (Built in Mingw) with the SVN(5205) patched as above.
It warned about a bunch of declared but not used stuff.
Then failed on reference to a bunch of C files using __chkstk_ms
I traced this to the cspice.a library.
This is the Nasa spice not the electrical simulator spice.

frmchg.c:-1: error: undefined reference to `__chkstk_ms'
outmsg.c:-1: error: undefined reference to `__chkstk_ms'
zzbodker.c:-1: error: undefined reference to `__chkstk_ms'
zzbodblt.c:-1: error: undefined reference to `__chkstk_ms'
zzekkey.c:-1: error: undefined reference to `__chkstk_ms'
spke18.c:-1: error: more undefined references to `__chkstk_ms' follow.

Still way over my head.
It is for reasons like these that I like working examples of a compiler with a project.
Were I not doing this as a favor or for pay I would have long since walked away.
I am helping a friend/customer make an interactive demo, hopefully using celestia as a display generator.

I seriously doubt the people actually doing the programming, and a very good job they are doing, realize how hard it is for a newbie to make sense of any of this stuff.
So what I am trying to do is lower the entry barrier.
I know some will say just use VS like a normal person.
Sorry, I HATE VS, I am also not fond of visual based languages in general.
They have their place, just not with me.

Doors.