Debian Gnu/Linux Tutorial

[krampenschiesser]

Well, i don't know if this helps somone but i really got fed up with searching through the whole forum.
So now i paste this Tutorial for other people using Debian Gnu/Linux who don't want to look through the whole forum.
These are only extracts from other Forum Articles which aren't posted from me but i'll make a link to every post.

1 Dependencies
2 Get the Ogre3D package
3 Installing Ogre3D
4 making a .deb File (not necessary)
5 Compiling a Sample
6 Known Bugs
6.1 bootstrap error
6.2 sample app can't find libOgreMain.so.3

1. Dependencies originally by l3m
http://www.ogre3d.org/phpBB2/viewtopic. ... n&start=25

first you have to get the dependencies:
# apt-get install libsdl1.2-dev libdevil-dev libfreetype6-dev

for gtk gui you also have to get:
# apt-get install libgtkmm2.0-dev libglademm2.0-dev

Then you have to get the CG from Nvidia:
ftp://download.nvidia.com/developer/cg/ ... nux.tar.gz
untar it with tar-xvf Cg-1.2.1-Linux.tar
then copy as root the files from the different dirs like bin lib etc. to your / dirs like /lib
/usr/bin etc.
As you can read below the new versions of cg are not yet supported.


2. Get the Ogre3D package originally by l3m
http://www.ogre3d.org/phpBB2/viewtopic. ... n&start=25

Either download the stable .tar.gz

http://www.ogre3d.org/modules.php?op=mo ... tit&lid=43

or get the latest version from cvs:

# apt-get install cvs ( just in case cvs isn't installed on your system yet )
$ cvs -d :pserver:anonymous@cvs.sf.net:/cvsroot/ogre login
$ cvs -z3 -d :pserver:anonymous@cvs.sf.net:/cvsroot/ogre co ogrenew

3. Installing Ogre3D originally by l3m
http://www.ogre3d.org/phpBB2/viewtopic. ... n&start=25

go to the ogrenew directory

#./bootstrap
#./configure
#make
#make install

I often got errors with the cvs versions. If they don't work try the latest stable.

4. Making a .deb File originally by badcamel (forgot link)
If you want to make a .deb file out of it you have to get checkinstall via # apt-get install checkinstall
then change to the ogrenew directory and type checkinstall
enter a description and avoid other symbols then a point(.)
fillout the right version number, name, description, and group.
After this you should have a working .deb file wich you can install and uninstall via dpkg -i ogre.deb or dpkg -r ogre.deb

5. Compiling a Sample
Change to your ogrenew/Samples/Common/bin dir.
Create a file called SampleApp.cpp with the sourcecode from
http://www.ogre3d.org/docs/Tutorials/Se ... pleApp.cpp
Save it and then type:
$ g++ -o test sample.cpp -DGCC_3_1 -DEXT_HASH -I/usr/local/include/OGRE -I/home/scar/ogrenew/Samples/Common/include -L/usr/local/lib/OGRE -lOgreMain
notice that the second include path /home/scar/ogrenew... must be your path to the ogrenew dir.
That should compile the sample app. Run it via ./test.
You need gcc 3.x to compile it. I used gcc 3.3.4 and it worked.

6. Known Bugs

6.1: # ./bootstrap doesn't work.
If your bootstrap file doesn't work you should try to get automake 1.9 via
# apt-get install automake1.9
then change to your /usr/bin dir.
Then replace your automake file with the automake1.9 file.
# rm automake; cp automake1.9 automake;
Then go to your ogrenew dir and open the bootstrap file with an editor.
Change the line:
if test -z "`automake --version 2>&1|head -n 1|egrep '1.[6-8]'`"; then
to
if test -z "`automake --version 2>&1|head -n 1|egrep '1.[6-9]'`"; then
It's simply changing the 8 to 9.
This should solve your problem.

6.2 sample app can't find libOgreMain.so.3

If your sample app doesn't find the libOgreMain.so or another lib you should copy the ogre libs from /usr/local/lib/OGRE to /lib
do this by # cp /usr/local/lib/OGRE/* /lib/
please notice that you shouldn't use the -r par.


I hope this could help some people.
Scar

[MadLion]

Just an advice for CG.
I have tried it with the new CG 1.3 (Beta 2!?) and have problems with it. It couldn't compile some thinks.
So i go back to an older version (1.1 i think, but now i will try 1.2.1) and the it works fine.

[sinbad]

The Cg 1.3 beta is not supported yet. It's on my list, but as with any beta releases you should revert to the stable if you get problems

[TSi]

6.1: # ./bootstrap doesn't work.
If your bootstrap file doesn't work you should try to get automake 1.9 via
# apt-get install automake1.9
then change to your /usr/bin dir.
Then replace your automake file with the automake1.9 file.
# rm automake; cp automake1.9 automake;
Then go to your ogrenew dir and open the bootstrap file with an editor.
Change the line:
if test -z "`automake --version 2>&1|head -n 1|egrep '1.[6-8]'`"; then
to
if test -z "`automake --version 2>&1|head -n 1|egrep '1.[6-9]'`"; then
It's simply changing the 8 to 9.
This should solve your problem.

With Debian, there's also the option of installing different versions of automake. (e.g. apt-get install automake1.8 alongside of automake1.9). Choosing which version will be invoked by running automake is a matter of running

Code: Select all

update-alternatives --config automake

and choosing which version you want.

6.2 sample app can't find libOgreMain.so.3
If your sample app doesn't find the libOgreMain.so or another lib you should copy the ogre libs from /usr/local/lib/OGRE to /lib
do this by # cp /usr/local/lib/OGRE/* /lib/
please notice that you shouldn't use the -r par.

Personally, I'm not a fan of poluting my linux installation by copying random files to random locations by doing what is written above. It's horrible to clean up afterwards =) Instead I propose that you do as I've done: write a small start script for your application.

Code: Select all

#!/bin/sh
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/lib/OGRE
./MyWildAndCrazyApplication

or, if you've got the OGRE.pc for pkg-config up and running, you can use

Code: Select all

#!/bin/sh
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:`pkg-config ogre --variable=libdir`
./MyWildAndCrazyApplication

I haven't tested this one though.

[krampenschiesser]

Nice Addon
I hope there will be more useful hints like this.
I am using Linux since 4 months and i am still learning new things.
So i am not afraid of criticism(correctly written?!)
Scar

[_mental_]

To get around the problem of not being able to find libOgreMain.so the best thing to do is to add /usr/local/lib to your /etc/ld.so.conf and re-run /sbin/ldconfig. This will tell the linker to look in /usr/local/lib. I highly recommend never copying anything to /lib, unless it is part of the base system.

[Balazs]

To get around the problem of not being able to find libOgreMain.so the best thing to do is to add /usr/local/lib to your /etc/ld.so.conf and re-run /sbin/ldconfig. This will tell the linker to look in /usr/local/lib. I highly recommend never copying anything to /lib, unless it is part of the base system.

But the libs are in /usr/local/lib/OGRE
I think it instead should be installed simply in /usr/local/lib
Then ld will find it (if you apply the above).

--
Greetings,
Balázs

[_mental_]

libOgreMain.so & libOgrePlatform.so get put in /usr/local/lib with a default install from source. Only the plugins get installed in /usr/local/lib/OGRE, but you don't have to move these if you have the following line in your plugins.cfg

PluginFolder=/usr/local/lib/OGRE

[MMind]

Files installed by the package manager of a linux distribution should not be installed in /usr/local/*.
As I don't think usage of "checkinstall" is compliant to packaging standards I thought I post my Ogre-Debian-Package scripts.
Created with "dh_make" for a library package an then modified they create 5 packages that can then be installed with dpkg.
They can be found on http://www.sntech.de/ogredebianfiles.tar.gz .
The archive should be extracted in the directory containing the ogre library and creates a new directory "debian" there.
After extracting build the packages with dpkg-buildpackage from "dpkg-dev".

Code: Select all

cd ogrenew
tar -xzf ../ogredebianfiles.tar.gz
dpkg-buildpackage -b -uc -rfakeroot

This creates the following packages in the parent directory of the ogre tree:
- libogre2: Ogre libraries, everything that is needed to run ogre-applications (last time I checked the soname of ogre was 2, therefor the name libogre2)
- libogre-dev: development files (headers, .so links, pkg-config file)
- libogre-doc: documentation (everything from Docs and below [runs makedocs.sh])
- ogre-bin: Binary files (xmlconverter, mesh upgrader)
- blender-ogrexml: Blender export script, including docs (after installing the exporter is usable for every user on that system)

Limitations & warnings:
- not tested on woody (I don't think it will build there), so use sarge or above
- package descriptions are not really informative, only some very short text to describe the package
- my last test of building was sometime in june, I think it should build, but I don't know exactly yet, later or tomorrow I will make a test build and update possible errors
- doxygen is needed for makedocs.sh, but not mentioned in the "Build-depends" field
- same goes fr cg
- libraries are stripped by default (this means debug symbols are removed, dramatically reducing the size of the libraries, so no 60mb libogremain.so.., but only 2mb) - if you want to compile with debug symbols put a "#" before the command "dh_strip" in debian/rules before the compilation

I hope this is useful

greetings Heiko

[edit]
I forgot:
libraries are installed in /usr/lib and /usr/lib/OGRE, so plugins.cfg must be changed
[/edit]

[MMind]

I have built Ogre (CVS from 03.09) and everything seems to work fine
another note:
the version value in debian/changelog should be set to something meaningful, e.g. actual date for cvs builds

[bad_camel]

I use checkinstall to install all my self-compiled stuff in debian, which adheres correctly to the standards. If it is the /usr/local/lib part that bugs you, this is not checkinstalls fault(as it simply executes your configured build system's install rule), and this can be changed in the flags of ./configure.

Debians checkinstall is modified to adhere to the debian standard as far as I'm aware. In fact it behaves quite differently from a stock checkinstall build as I use it in fedora core as well.

However, each to his own, I'm not saying your method is any less valid.

[MMind]

If it is the /usr/local/lib part that bugs you, this is not checkinstalls fault(as it simply executes your configured build system's install rule), and this can be changed in the flags of ./configure.

Thats part of what is bugging me
Mostly I dislike the "ogre.deb" something. I prefer the libLIBNAMESO_VERSION-REVISION_ARCH.deb syntax that is used everywhere else. (same for libLIBNAME-dev, ...-doc,...), notice the split in runtime library, development files, library documentation and so on ...
(somewhere in the packaging policy this is defined)
I know that ogre isn't a candidate for official inclusion in debian main, due to its dependency on NVidias Cg (nonfree), but I prefer do have my private packages conforming to the standards, and also have the blender exporter installed, which isn't by "make install".
This is only my opinion, for keeping track of manually installed things checkinstall seams ok.

Off on vacation and greetings
Heiko

[edit]
see: http://www.nl.debian.org/doc/debian-pol ... dlibs.html
for completeness sake
[/edit]

[bad_camel]

Again, this is not checkinstall's fault

Checkinstall has to guess what you want for each field, so it uses the directory name. All you have to do is get used to what it needs(which takes 10 minutes really), and you will be good.
The other way is to manually change the field before package creation which is a painful way to do it.

I actually like using it's directory method as it helps me keep track of all my development stuff in terms of versions, release, and in the case of cvs, tag, date, etc

[rogma]

First thanks for the tutorial.

I have just made a successful install of ogre 0.14.1 on a Debian/Sarge and it could not compile until I installed the following packages :

libmng-dev
libjpg62-dev
libpng12-dev
libtiff4-dev

So it seems to me that these packages are part of dependencies.

Rogma

[_mental_]

Those packages aren't direct dependancies of OGRE, they are dependancies of DevIL.

[rogma]

Thus it must be a bug in dependency list for libdevil-dev...

[naterajj]

MMind I followed your instrcutions, but I get the following error on Debian/testing:

After all the compiling I get this:

Generating example index...
Generating file member index...
Generating namespace member index...
Generating page index...
Generating graph info page...
sh: line 1: dot: command not found
Generating style sheet...
Generating graphical class hierarchy...
sh: line 1: dot: command not found
dh_movefiles
dh_installchangelogs ChangeLog
install: cannot stat `ChangeLog': No such file or directory
dh_installchangelogs: command returned error code 256
make: *** [binary-arch] Error 1

[fog]

Very preliminary debian packages for 0.14.1 are available from http://people.debian.org/~fog. "Very preliminary" means that there are no examples and no Cg support and some help is needed to finish them right.

Cg will be added as a "contrib" package, depending on the installer package nvidia-cg-toolkit (currently entering experimental). This is mainly a problem with nvidia cg tool being non free.

The examples depend (so i was told, but please feel free to update this information) on not freely redistributable media so will need to trim them down and include in the ogre-doc (or ogre-examples, ogre-doc is already 10Mb) package only the freely redistributable ones.

Finally the packages are based on the debianization scripts found in this thread; I am working to have the python bindings work on linux and then include them.

[fog]

At http://people.debian.org/~fog there are some Debian packages of last (2004-10-05) CVS snapshot. I am planning to continue providing snapshot packages while I continue working on the .debs.

I am able to use the packages to compile and run almost all the examples but right now I can't distribute even the simplest one because of license problems. For example we can't distribute the OgreCore.zip file because of the fonts inside it. I am building a full set of configuration files and media but I really don't want to maintain a custom subset of the Samples subdirectory. Would it make sense to change the non-free fonts with free ones and repacking some of the zips to clearly separate free/non-free stuff? Are patches doing just that accepted upstream?

(Btw, I am sorry for all this licensing talk, I understand some people can not like it. I simply want to have ogre widely available in Debian main and we have some rules to respect.)

[sinbad]

I was under the impression that the fonts we included were legal to redistribute, even though they are originally from MS (I remember checking this out). If you know otherwise, and have other free alternatives, I'm certainly keen to resolve that.

[MMind]

MMind I followed your instrcutions, but I get the following error on Debian/testing:

After all the compiling I get this:

Generating example index...
Generating file member index...
Generating namespace member index...
Generating page index...
Generating graph info page...
sh: line 1: dot: command not found
Generating style sheet...
Generating graphical class hierarchy...
sh: line 1: dot: command not found
dh_movefiles
dh_installchangelogs ChangeLog
install: cannot stat `ChangeLog': No such file or directory
dh_installchangelogs: command returned error code 256
make: *** [binary-arch] Error 1

somewhere in debian/docs the ChangeLog file is mentioned. Wenn I do a cvs checkout, I use cvs2cl to generate it (to see whats new) and I seem to have it included in the debian/docs file. Removing this reference or having this file should fix the problem

[MMind]

I was under the impression that the fonts we included were legal to redistribute, even though they are originally from MS (I remember checking this out). If you know otherwise, and have other free alternatives, I'm certainly keen to resolve that.

Freeness in debian needs more than the right to redistribute.
Packages in Debian needn't to conflict with the Debian Free Software Guidelines (DFSG) [the "Opensource Definition" is based on them]
see: http://www.debian.org/social_contract#guidelines
To be "free" (as in speech / not as in beer) elements need also to be freely modifiable by users/developers and still redistributable. Also some other criteria need to be fullfilled (not discriminating against certain users, no need to contact copyrightholder on use, etc).

[Jezze]

I've switched from Mandrake (yuck) to Ubuntu now and I am about to install OGRE... does anyone know if this tutorial applies to Ubuntu as well sense it also uses Debians .deb files...?

[fog]

I've switched from Mandrake (yuck) to Ubuntu now and I am about to install OGRE... does anyone know if this tutorial applies to Ubuntu as well sense it also uses Debians .deb files...?

ubuntu is debian after all. you can use my debian packages, see about 4 messages above.

[fog]

I was under the impression that the fonts we included were legal to redistribute, even though they are originally from MS (I remember checking this out). If you know otherwise, and have other free alternatives, I'm certainly keen to resolve that.

The ms "core fonts" are freely redistributable with some limitations and that's not enough for debian. also, some of the models/textures in the Samples are not "free" in the Debian Free Software Guidelines sense (for example are only free for non-commercial purpouse.)

What I can do (if you sinbad and other ogre core developers agree) is to send some patches to neatly separate the "really free" content from the "not really free" one, making easier for us to have ogre in debian and for other people distinguish what media in the package as a ogre-like license (i.e., the equivalent of ogre's LGPL) and what does not.