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 -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110822182557.gv15...@caffeine.csclub.uwaterloo.ca
