My progress on armhf
So having now got my MX53QSB board I have been fixing a few things.
My first task was installing vim because there is only so many times
I can handle typeing 'vim /etc/apt/sources.list' and being told 'no
such command'. Building vim requires libtool, which wasn't building due
to a testcase problem. Turnst out the package was supposed to have been
fixed already. So I tried building it. Still fails. Apparently the
patch didn't actualyl get applied in the new version that claimed to
fix it. Bug updated and the maintainer seems to be working on really
getting it fixed. With the fix in place libtool builds fine, and I was
able to build and install vim. Yay!.
I then started poking at crystalspace. No idea why, but it was on the
wiki as something that didn't work. There was a patch to try adding
arm support done a while ago, although it clearly was never tested.
It compiles on armel, but I am certain it doesn't actually run due to
a mistake in the patch causing an undefined symbol to be hit at runtime.
crystalspace also does not compile on armhf since the arm support patch
(that doesn't work) uses instructions that don't work in thumb mode
(swpb specifically). Why crystalspace can't use pthread locks rather
than reinventing the wheel in assembly I can't imagine.
I wrote a new assembly free version (which is not arm specific as a
result) using gcc 4.1+ intrinsic atomic functions instead. This does
compile on thumb and hence armhf. crystalspace now had some stuff
working, but anything involving the xwin.so plugin did not. Lots of
missing symbols.
The missing symbols turned out to be due to the use of relaytool, which
is some old hack job to do on demand library loading rather than linking
against all the needed libraries. crystalspace only uses it for xwin.so.
relaytool is only implemented to work for x86, x86_64 and partially
for powerpc. This of course meant the xwin.so doesn't work on armhf
(or armel or anything else for that matter). Adding --disable-relaytool
to the configure command solved that, and now I can actually run the
various crystalspace tests although since I don't have opengl working in
my chroot (no idea if I could get that working) I have to run them with
'-video=software' and use that renderer instead. But at least it seems
to work.
I am going to send patches to the crystalspace bug report to fix those
issues.
I also needed gdb to track down some of the issues in crystalspace,
and it built and installed just fine (possible because libtool was
already fixed).
Any suggestions for what to fix next?
--
Len Sorensen
Reply to: