General Thread

by Aardappel on 01/05/2002 01:55, 15499 messages, last message: 12/08/2021 21:22, 8826362 views, last view: 12/09/2021 04:12

for questions, announcements etc.

   Board Index   

#1725: Re: Compiling Cube In Linux

by D.plomat on 07/11/2003 00:46, refers to #1724

I also have nvidia drivers... didnt' had something to do about it for compiling, cause it's already here.
I had the Mesa libs already before installing, so maybe as Thalion says there are still some headers on my machine that remains from Mesa.
I'm on a RH7.3 (with lots of libs -binary- updated, but this doesn't really matter). You just have to install the *-devel.rpm packages to compile Cube, as you would need the *.rpm packages to run Cube.
I just went into source/src and did 'make', and get the 'cube_client' and 'cube_server' binaries.
What error messages do you get from make?
If it's OGL/Mesa related, maybe you can extract some files from the Mesa RPMs without overwriting your nvidia drivers installation.

reply to this message

#1726: Re: Compiling Cube In Linux

by pushplay on 07/11/2003 05:58, refers to #1725

I don't want to boot into linux just to get the error message back, but it was looking for an OpenGL header file and didn't find it. I'm tempted to just release with the win binaries and source for the linux users. Linux users like painful install processes anyways, right?

reply to this message

#1727: Re: Compiling Cube In Linux

by Thalion on 07/11/2003 09:14, refers to #1726

That was exactly what I experienced. My solution was to install Mesa, then NVidia.

Oh, BTW, what's the problem with the drivers? They are self-installing, after all. Just as long as you're root... =)

reply to this message

#1728: Re: Compiling Cube In Linux

by pushplay on 07/11/2003 10:54, refers to #1727

Last time I installed the nvidia drivers I had to edit some config file by hand. If you don't know what you're doing that's a pretty big deal.

reply to this message

#1729: Re: Compiling Cube In Linux

by D.plomat on 07/11/2003 12:26, refers to #1728

I suppose it was /etc/modules.conf and/or /etc/X11/XF86Config-4.
When you install nvidia drivers, it can be done via self-extractor/installer or rpm package(i used this). But you still need a line in modules.conf to tell the kernel to load the kernel part of the driver on startup, then specify in XF86Config-4 the X server to use this driver, and activate its GLX extension.
If i remember correctly, there also are some headers in some nvidia packages, and also in mesa, but there are correct OGL headers already included in Cube source to avoid missing with nvidia/Mesa etc...
Well a moment you're running Linux, if you can note the error and missing file name, i can probably give you the way to install it on your system without interfering with nvidia/mesa.
Or... i you want, you can send me the sources and i can compile them for you, and send you back the cube_client & cube_server binaries.
On my system i just
cd cube/source/src
make
and it compiles in <10 sec :D

reply to this message

#1730: Strange place for GL headers... not very intuitive i agree

by D.plomat on 07/11/2003 15:39

First i was wondering why don't i have something like OpenGL-devel or Mesa-devel on my machine, so i assumed Cube compile needed only those in it's source dir.

Looks like they are in the package XFree86-devel, just take a look at the very end of the page, the file list: one of those could be what make misses.

http://fr2.rpmfind.net//linux/RPM/redhat/9/i386/XFree86-devel-4.3.0-2.i386.html

/usr/include/GL
/usr/include/GL/GLwDrawA.h
/usr/include/GL/GLwDrawAP.h
/usr/include/GL/GLwMDrawA.h
/usr/include/GL/GLwMDrawAP.h
/usr/include/GL/gl.h
/usr/include/GL/glext.h
/usr/include/GL/glu.h
/usr/include/GL/glx.h
/usr/include/GL/glxext.h
/usr/include/GL/glxint.h
/usr/include/GL/glxmd.h
/usr/include/GL/glxproto.h
/usr/include/GL/glxtokens.h
/usr/include/GL/osmesa.h

As they're only headers, not libraries/binaries, they won't mess up your nvidia drivers. As they're not used by the system (except when you compile an OGL app), you can safely make a backup copy of /usr/include/GL before.
So it looks like you just have to find and install the XFree86-devel package corresponding to your distro version on the CD or with http://rpmfind.net if you're using a Mandrake or RedHat

For zlib, Thalion, i think that if you don't choose the 'development station' option during the install, most distro will install only zlib package (binary library), not zlib-devel one (headers, api-specific build tools etc). I may be wrong, but i believe that if you need packages a and b to run app y, then you need packages a-devel and b-devel to compile y. At least, it looks like RH and Mdk does this way (this may sound total nonsense for a Gentoo or LFS user ;) don't know for debian/suse/slack...)

reply to this message

#1731: Re: Strange place for GL headers... not very intuitive i agr

by Thalion on 07/11/2003 19:21, refers to #1730

If you didn't install a development station, you've made a wrong decision in considering to use Linux =) At least, that's how I put it.

reply to this message

#1732: Re: Strange place for GL headers... not very intuitive i agr

by pushplay on 07/12/2003 02:16, refers to #1731

I didn't want to use up all kinds of hard drive space for something I didn't see that I wouldbe needing.

I installed both that devel rpm and the latest nvidia driver and it still says it can't find:
gl.h
glu.h
glext.h

reply to this message

#1733: Re: Strange place for GL headers... not very intuitive i agr

by Thalion on 07/12/2003 07:37, refers to #1732

Mesa =)

reply to this message

#1734: Re: Strange place for GL headers... not very intuitive i agr

by pushplay on 07/12/2003 09:08, refers to #1733

Fine, I give up, I'll install Mesa.

reply to this message

#1735: Re: Strange place for GL headers... not very intuitive i agr

by D.plomat on 07/12/2003 15:40, refers to #1734

Took another look to rpmfind.net, RedHat version <= 7.2 had those headers in package Mesa-devel, so you may need this also. Still, once you have installed packages, you can check in /usr/include/GL, if you have those headers in it, normally it will find them. If they are physically here and make can't find them, then it may be some misconfigured env vars for the build environment and it's really gonna be a pain in this case.
Too bad that most distro's can't agree on some standard path and package names :(
Still, what's your distro and version? I'll take a look on Google & forums, if your distro does something unusual with the GL headers, it's most likely that many others had problems compiling OGL applications.

reply to this message

#1736: Re: Strange place for GL headers... not very intuitive i agr

by Thalion on 07/12/2003 17:29, refers to #1735

Considering Linux distros - when such things happen, I usually think how (Free/Open/Net)BSD is much better. By the way, NVidia released new version of drivers for FreeBSD; maybe Cube will run with those? I've got it compiling on FreeBSD back then (several month ago), but couldn't run because of buggy drivers. It would be great if it works now. I'll ask my local BSD guru to check it out =)

reply to this message

#1737: .

by pushplay on 07/13/2003 00:17

Thanks D.plomat, but I wouldn't ask you to make that kind of effort until I've tried the Mesa route.

reply to this message

#1738: Text not appearing and no water either

by bigun on 07/13/2003 08:28

My hats off to you folks! The best engine for it's size bar-none. But for some reason, my text is not appearing on my HUD or my menus when I use the escape key. Also, there is no water appearing, only a pure white flowing glob. Is there a patch to fix this or is this because of hardware issues. Lemme know if you need more info...

reply to this message

#1739: Re: Text not appearing and no water either

by pushplay on 07/13/2003 08:40, refers to #1738

You either need to update your drivers or change the texture sizes to be 1/2 of what they are now.

This is a very well documented issue.

reply to this message

#1740: Re: Text not appearing and no water either

by Thalion on 07/13/2003 09:43, refers to #1739

Or buy something else instead of your 3Dfx card =)

reply to this message

#1741: :-?

by Bascule on 07/14/2003 09:24

D.plomat said '(this may sound total nonsense for a Gentoo or LFS user ;) don't know for debian/suse/slack...)'

Well, this whole thread sounds like hard work to me! I have some high-level (corporate) knowledge of Unix/Oracle systems and had thought about running Linux at home, but it's this kind of difficulty that puts me right off.

Is there really no easy, standard way to get Linux installed and working?

I'm inclined to follow Aard's philosophy that many people contributing seemingly at random to open-source projects just makes for confusion, not a better product.

reply to this message

#1742: ..

by Thalion on 07/14/2003 11:44

The thing is, Linux itself is mostly just a kernel. Most associated libraries and tools don't belong to it (they are cross-platform), and often can be replaced (just count the number of shells out there!). So, the Linux distro is a package of a kernel (some version of it; there are several to choose from), libraries, and programs. But the approach can be different. For example RedHat and Mandrake supply you with precompiled binaries, with separate sources. On the other hand, with Gentoo, you only get the sources, and have to compile the entire system from scratch, starting from the kernel and glibc. Administration philosophy is also quite different: in Mandrake, you get all those nifty "control centers" for doing this and that, in Slackware (and Gentoo I think) you just edit your config files. Furthermore, the question arises how to distribute the software. Right now we have good ol' .tar.gz (or good new .tar.b2), then RedHat's evil .rpm, then Debian's own .deb, and then Gentoo's nice .tbz2. And guess what? Your RedHat-made .rpm might not install that easily on his Slackware system... As if it is not enough, the principles of separating software into packages are far from uniformity. As it was mentioned, Mandrake, for example, separates precompiled binary libraries (.so) from their sources and headers. Gentoo, obviously, does not.

All in all, it's a mess. But it's not as bad as it seems. Most [sane] people .tar.bz2 what they distribute, anyways, with optional RPMs for most popular RPM-based distros. So, if you get the .tar.bz2, you will be able to install it on any distro out there without any additional fuss (and get both the binaries and the headers). That's why I never download RPMs for my Mandrake...

reply to this message

#1743: this channel

by hungerburg on 07/14/2003 11:54

this channel turned into a linux support list. maybe start a seperate thread?

reply to this message

#1744: Re: this channel

by pushplay on 07/14/2003 12:11, refers to #1743

I think general is a fine place for this sort of thing.

Personally, I use RedHat. It's usually easy enough to get going, and you can always change to another distro later if you want to get more hard core.

If you only have one computer I recommend setting up a dual boot until you feel confortable with linux. There's a lot you can tinker with, and messing with the wrong thing could leave you stuck at a command prompt or worse.

reply to this message

   Board Index