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
Attachment:
signature.asc
Description: PGP signature