Testing request: Autopackage builds with dependencies

Website · Post by **Z-Man** » Fri Mar 10, 2006 4:01 pm

I figured out it is quite easy to let the autopackage builds check dependencies prior to installation, you just have to add stuff like

Code: Select all

require @gnu.org/libstdc++ 3

in the Prepare section. Autopackage comes with predefined checks for all libraries we use. Automatic installation if they are missing probably does not work, and I doubt it ever will, but you'll get rudimentary instructions.

I added the corresponding checks, now I'm doing builds and need help testing them. Please fetch the attached packages for your architecture and the rc4 packages from AABeta and test both. Report back whether
- the attached builds pass the dependency checks
- if yes, whether they work after installation
- independently, whether the rc4 build works (it doesn't do checks)
The client builds would be more important.

The packages in this post are AMD64 packages without map future proofing that should run on pretty old systems.
Installation instructions: Download, run bzip2 -d on the file, execute "sh <path to unzipped file>".

Background information: The AMD64 builds are not perfect. X86 builds, to come later today, are statically linked against a specially compiled version of libxml2 that is compatible with older versions of glibc and has all the features we need. The same procedure fails on AMD64, I can either link statically with a good version of libxml2 that needs glibc 2.3, or link dynamically. The dependency checker cannot differentiate between libxml2 2.6.11 and 2.6.12, and we are using a feature of 2.6.12 for our map future proofing. So, in order to avoid the package failing silently and miserably on systems with 2.6.11, I have to disable map future proofing and depend on libxml2 2.6.0.

Website · Post by **Z-Man** » Fri Mar 10, 2006 4:24 pm

The files here include are full featured AMD64 builds, but require glibc 2.3.

Before unzipping, you need to merge the two client files with

Code: Select all

cat armagetronad-0.2.8_alpha20060310.x86_64-generic-linux-gnu.glibc.2.3.package.1.bz2 armagetronad-0.2.8_alpha20060310.x86_64-generic-linux-gnu.glibc.2.3.package.2.bz2 > rmagetronad-0.2.8_alpha20060310.x86_64-generic-linux-gnu.glibc.2.3.package.bz2

(one line).

Are there opinions on what the final build should be? Obviously, if one does not work in these tests, it's out

Apart from that, I'd try to make the client the version with libxml2 statically linked (as desktop systems can be expected to have a reasonably up to date glibc, and the DTD donwload will be needed) and the server dynamically linked with the old libxm2 version (servers are set up conservatively and don't need DTD download as much as the client).

x86 builds will follow in some hours.

gnorty · Post by **gnorty** » Fri Mar 10, 2006 4:39 pm

I don't know if this is related, but I tried to compile vanilla x86 version rc4 last night and it failed to compile, reporting: -

Code: Select all

In file included from ./render/rGL.h:10,
                 from ./render/rTexture.h:33,
                 from engine/eAdvWall.cpp:30:
/usr/include/SDL/SDL_opengl.h:45:58: error: GL/glu.h: No such file or directory

]

configure worked fine, reporting no problems, and I went back to the rc3 source and compiled that with no problem.

mandriva 2006

Website · Post by **Z-Man** » Fri Mar 10, 2006 10:01 pm

That's unrelated and bizarre, none of the files involved had any significant changes. Could you try to build both versions again and send config.*, Makefile and src/Makefile from each?

Also, the output of "locate glu.h" would be informational.

Post by **Tank Program** » Fri Mar 10, 2006 10:03 pm

Looks like the system is missing certain headers. Are you sure the complete development suite is installed? Can you compile other OpenGL games?

Website · Post by **Z-Man** » Sat Mar 11, 2006 12:07 am

Tank: rc3 did work for him, that's the strange thing.

Back on topic: x86 autopackages attached. Unzip and execute to install.

Website · Post by **Z-Man** » Sun Mar 12, 2006 2:44 pm

Bump. Gnorty?

And zero downloads so far, boo! All you have to do is download, install and report back. Autopackage supports installing as a normal user in your user's home directory, so there is no risk of ruining your system.

gnorty · Post by **gnorty** » Sun Mar 12, 2006 10:25 pm

Sorry for the delay - work commintments atm mean I dont have the time to mess with arma. Will do as you asked sometime monday.

gnorty · Post by **gnorty** » Tue Mar 14, 2006 12:23 pm

Ok, apologies again for the delay. Attached are the files you requested.

also

locate glu.h
/usr/X11R6/include/GL/glu.h

Post by **Lucifer** » Tue Mar 14, 2006 1:05 pm

Code: Select all

# Checking for required C library versions ... passed
# Checking for Standard C++ library ... passed
# Checking for Simple DirectMedia Layer (SDL) ... passed
# Checking for OpenGL Graphics Toolkit ... passed
# Checking for OpenGL Utility Library ... passed
# Checking for SDL Image Library ... passed
# Checking for libpng graphics library ... passed
# Checking for zlib compression library ... passed

Minor note: If someone has problems using the graphical installer, they can pass "-t" to the autopackage to force it to use text mode.

anjori · Post by **anjori** » Tue Mar 14, 2006 1:58 pm

http://forums.armagetronad.net/viewtopic.php?p=44475#44475

Code: Select all

# Checking for required C library versions ... passed
# Checking for Standard C++ library ... passed
# Checking for Simple DirectMedia Layer (SDL) ... passed
# Checking for OpenGL Graphics Toolkit ... passed
# Checking for OpenGL Utility Library ... passed
# Checking for SDL Image Library ... passed
# Checking for libpng graphics library ... passed
# Checking for zlib compression library ... passed

Website · Post by **Z-Man** » Tue Mar 14, 2006 2:35 pm

Thanks, anjori and Lucifer. I assume the installed program worked?
What are the tested OSes? Mepis for anjori? Lucifer, still running Mandriva?

Gnorty: thanks a lot. It seems we're forgetting to put the X headers into CXXFLAGS. The required directive to make the compiler find glu.h is only active in CFLAGS, which isn't used for C++ files at all. Other systems have the GL headers in /usr/include where they are found without problem. It's extremely odd that rc3 does work, because the only non-cosmetic differences in rhe archives you sent where optimization options that don't affect the preprocessor.

Could you try configuring rc4 with

Code: Select all

CXXFLAGS=-I/usr/X11R6/include ./configure

and compile again? (You may need to run make distclean before that, configure will tell you if that's the case.) If it doesn't work, I'd like the full output of both configure and make.

gnorty · Post by **gnorty** » Tue Mar 14, 2006 9:02 pm

Works fine when compiled that way - Thanks

Post by **Lucifer** » Tue Mar 14, 2006 9:25 pm

I'm in Kubuntu now. I haven't actually tested the installed autopackage.

I just copied the console output with the checks in it, heh.

/me goes to test it real quick.

Ok, works. At least it gave me a splash screen and some other stuff, and then probably overwrote my user.cfg from cvs head, thus wiping out all my music settings.

(doh!)

Website · Post by **Z-Man** » Tue Mar 14, 2006 9:36 pm

Still think it would be a bad idea to let CVS and beta use separate config directories?