Sorry for re-triggering an old thread, On Sun, 8 Mar 2009 21:07:29 +0100, David Paleino wrote:
> On Sun, 8 Mar 2009 16:49:33 +0100, Evgeni Golov wrote: > > > [..] > > David, is there any chance that libx86 will be updated someday? Esp > > because upstream of v86d has an updated 0.10 in his git at > > http://repo.or.cz/w/v86d.git and Debian's v86d is not using it in > > favour of not build duplicate code. > > > > All other (incl David), is there any interest in forking libx86 and > > using it globally instead of fixing that ftbfs 7 times? > > I prepared a package with an updated LRMI: > > http://alioth.debian.org/~hanska-guest/apt/unstable/libx86_1.1+ds1-3.dsc Which now FTBFS on anything non-x86. Grin. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=533259 Matthew, could you have a look at that package again? lrmi.h (from LRMI 0.10) encloses everything into #if defined(__i386__) && (defined(__linux__) || defined(__NetBSD__) \ || defined(__FreeBSD__) || defined(__OpenBSD__)) thus the cited bugreport. *But* even removing that #if, it would FTBFS, because we're not building x86-common.c anymore (since it has been merged into lrmi.c), but x86emu used symbols from there! So the current build only works on i386. I don't know what exactly the x86-specific code is, I tried some patching but nothing came out of it. Really, we should split a x86-common.c out of the new lrmi.c, but I don't even know where to start. Any help is greatly apreciated :) Kindly, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 ----|---- http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
signature.asc
Description: PGP signature