The unstable repos contain the 3.11.5 kernel, quite recent stable version. Radeon 2.33 is probably the version of radeon from the 3.10 kernel. 3.11 has 2.34 too AFAIK. xserver-xorg-video-ati is indeed at 7.2 (this is the X servers driver).
Originally Posted by jery
Multiarch mesa is really fun on Debian (NOT):
You need all the stuff you have for mesa, the i386 version installed and build with the forced CPP, CXX flags + the --enable-32-bit, --disable-64-bit flags, its quite that simple ONCE YOU SOLVED THE DAMN DEPENDENCIES:
The problem is that the debian -dev packages are mostly NOT multiarch capable on Debian: its because both amd64 and i386 versions contain the include file(s) which are identical btw. The libraries have no such issues, as they are stored in the arch-dependent lib subfolders.
The result is that you can install only one of them at once. I thrown in the towel and installed the amd64 versions and downloaded each needed 32 bit -dev package and just extracted them. Had no issues compiling.
My 32-bit configure options (really good idea to store them in a script) - note that it has LDFLAGS forced, its because for some reason the compiler wanted to use the 64 bit libs and i disabled llvm mainly because llvm isnt multiarch and im lazy to solve that as i dont see any real benefit of using it:
To compile for both archs, you need to do a "make distclean" between the builds to make sure everything built previously is cleaned up.
./autogen.sh --sysconfdir=/etc --prefix=/usr --libdir=/usr/lib/i386-linux-gnu --enable-debug \
LDFLAGS="-L/usr/lib/i386-linux-gnu -L/usr/lib" \
--disable-64-bit --enable-32-bit \
--enable-egl --enable-gles1 --enable-gles2 \
I build the mesa deb packages with checkinstall (mesa32 for i386, because for some reason if i name both amd64 and i386 packages the same way, dpkg messes stuff up) - to circumvent the issues with files from the default system mesa packages (quite a few and cannot be uninstalled), i added all packages that my deb conflicted with to the "replaces" line - so the files in the new mesa packages will not be upgraded when a system mesa library is upgraded (because the second installed package that claims the files will keep them).
My deb creator script:
64-bit (i know i have certain i386 replaced packages, but it didnt work otherwise):
32-bit (notice thenodoc option and excluded files, those are in the 64 bit package and i needed to avoid conflicts):
fakeroot checkinstall --install=no --replaces libgles1-mesa:amd64,libgl1-mesa-dev,libglapi-mesa:amd64,libgles2-mesa:amd64,libgbm1:amd64,libegl1-mesa-dev,libgl1-mesa-dri:i386,libgl1-mesa-dri:amd64,libgl1-mesa-glx:amd64,libegl1-mesa:amd64,libgl1-mesa-swx11:amd64,libegl1-mesa-drivers:amd64,libosmesa6-dev:amd64,mesa-common-dev --pkgname=mesa --pkgversion=10.0-dev-`git describe` --pkgarch=amd64 --backup=no
Hmmm. Took me some time to figure these out. Now i have a master build script that pulls the newest commits from the git, builds the mesa (both amd64 and i386), glamor and xf86-ati .debs in one step.
fakeroot checkinstall --install=no --replaces libgles1-mesa:i386,libgl1-mesa-dev,libglapi-mesa:i386,libgles2-mesa:i386,libgbm1:i386,libegl1-mesa-dev,libgl1-mesa-dri:i386,libgl1-mesa-dri:i386,libgl1-mesa-glx:i386,libegl1-mesa:i386,libgl1-mesa-swx11:i386,libegl1-mesa-drivers:i386,libosmesa6-dev:i386,mesa-common-dev --pkgname=mesa32 --pkgversion=10.0-dev-`git describe` --pkgarch=i386 --backup=no --exclude=/etc/*,/usr/include/* --nodoc