Tag Archive: mesa


After getting Kodi running on my BananaPi, some issues remained, For example, there was no visualisation while playing music. It turned out that visualisations are split of from the main kodi package. While in the upstream Arch Linux, the visualisation packages are in the repository, they’re not in the repository for ArchLinuxARM. Compiling the modules myself gave a plugin but no visual effects. The cause turned out to be the visualisations linked against the MESA implementation of OpenGLES, rather then the sunxi implementation.

To make it work with the sunxi header files, edit the /usr/lib/pkgconfig/glesv2.pc file, and make the includedir point to
includedir=${prefix}/include/GLES2
. When compiling visualisations now, they work perfectly.

Another problem, mentioned in previous post, was the crash on using the Media Library. The crash on the Media Library seems like an issue not related to the Mali/Allwinner specific. Attaching a debugger revealed the following:

#0  0xb5b05c2c in std::local_Rb_tree_decrement (__x=0x17584e4) at /build/gcc/src/gcc/libstdc++-v3/src/c++98/tree.cc:98
#1  0x0044d184 in std::_Rb_tree_iterator > std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_emplace_hint_unique, std::tuple<> >(std::_Rb_tree_const_iterator >, std::piecewise_construct_t const&, std::tuple&&, std::tuple<>&&) ()
#2  0x00b72018 in DatabaseUtils::GetDatabaseResults(std::__cxx11::basic_string, std::allocator > const&, std::vector > const&, std::unique_ptr > const&, std::vector, std::allocator > >, std::allocator, std::allocator > > > >&) ()

At #2, we see a std::__cxx11::basic_string, while in #0, we see some c++98 references. It seems like a C++ 11 String is getting into some C++ 98 code. The gcc documentation states

Not all uses of the new ABI will cause changes in symbol names, for example a class with a std::string member variable will have the same mangled name whether compiled with the old or new ABI. 

A quick google reveals users of other ARM boards are suffering from the same issue, and, as my analysis of mixing up C++ 11 and C++ 98 code, seems confirmed by this forum thread.. So I tried a build from AUR with the suggested CXXFLAGS=--disable-libstdcxx-dual-abi added to the PKGBUILD. This can by done by adding export CXXFLAGS=--disable-libstdcxx-dual-abi just below export PYTHON_VERSION=2 (line 81).

For each package built from AUR, we need to add armv7h to the arch section. The AUR is targetting upstream ArchLinux, and thus only adding i686 and x86-64 to the supported architectures.

Also note: select jre7 when asked what jre version is to be instaled. jre8 will crash during compilation.

However this doesn’t work. It complains about missing libcrossguid, even though it is installed. The real issue here is that the compiler (gcc 6.1.1) doesn’t recognise the flags I gave it.

cc1plus: error: unknown pass libstdcxx-dual-abi specified in -fdisable

Another compiler flag that should disable the new ABI is-D_GLIBCXX_USE_CXX11_ABI=0. This appears to be accepted by the gcc 6.1 compiler. I was unable to finish the build due running out of space on the /tmp file system. As this process has taken up enough time today already, I’ll finish it another time

Back in 2011 I used to trade some bitcoins at an exchange called Bitcoin7. This exchange got hacked and I lost all my bitcoins and euros in my account over there and I lost my interest in cryptocurrencies. However, since the exchange rate of the bitcoin got a lot higher then back then, I’ve decided to take a look at it again.

I’m also thinking about doing a bit of mining. I mean… there is a fancy graphics card in my laptop, and I am no gamer, so, mining is the only purpose of the damn thing. However, getting OpenCL working using free software only (free, as in open source. not using proprietary binary blobs as driver) is not a trivial task. The open source nvidia driver, nouveau, does not support OpenCL at all, therefore my HP EliteBook 8530w is out of the question. My HP EliteBook 8570w however, got an ATI/AMD graphics card. With this card, OpenCL should be able to work. However, support is not included in the mesa package available in the repository. In the AUR repository there is a package mesa-cl, however, it fails on compiling a dependency, the libclc-svn package, also from AUR. As I look at the build instructions for GalliumCompute, it seems they compile a llvm/clang with experimental r600 support. I suppose the repository version of llvm/clang misses this configuration option, which may be the cause of this build failure.

Therefore, I am compiling some stuff manually, according to the instructions on http://dri.freedesktop.org/wiki/GalliumCompute/. I usually prefer not to install software which is not managed by pacman. Having files floating around in my root file system that are not managed by any packet seems a little messy to me.

Anyhow. mining… I might have a look at mining both bitcoins and litecoins. Possibly other cryptocurrency as well later, but for now, bitcoins and litecoins will be the thing I will look at. I might possible also have a look at an ASIC for bitcoins. I am considering ordering an USB Block Erupter.

However… synchronising with the bitcoin and litecoin networks takes forever.