i686-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -fomit-frame-pointer -DNDEBUG -m32 -march=i686 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_INTERFACE_VERSION__=0x00030101 -fPIC -I/usr/include/python2.4 -c src/fsys/reiser/reisermodule.c -o build/temp.linux-i686-2.4/src/fsys/reiser/reisermodule.o -fno-strict-aliasing -Wall -Werror src/fsys/reiser/reisermodule.c:20:26: dal/file_dal.h: No such file or directory src/fsys/reiser/reisermodule.c: In function `file_dal_close': src/fsys/reiser/reisermodule.c:49: error: structure has no member named `dev' src/fsys/reiser/reisermodule.c:50: warning: implicit declaration of function `dal_free' src/fsys/reiser/reisermodule.c: In function `reiser_fs_open': src/fsys/reiser/reisermodule.c:221: warning: implicit declaration of function `file_dal_open' src/fsys/reiser/reisermodule.c:221: warning: assignment makes pointer from integer without a cast error: command 'i686-pc-linux-gnu-gcc' failed with exit status 1 make[1]: *** [build] Error 1 make[1]: Leaving directory `/var/tmp/portage/xen-tools-3.0.2-r1/work/xen-3.0.2/tools/pygrub' make: *** [all] Error 2 make: Leaving directory `/vGentoo Base System version 1.6.14
Created attachment 89442 [details] emerge --info
Looks like the same problem was reported upstream and marked invalid because it worked for them on Debian - see http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=573 As far as I can tell, the problem is that pygrub (part of app-emulation/xen-tools) is expecting progsreiserfs v0.3.0, which provides /usr/include/dal/file_dal.h . The only version of progsreiserfs in portage is 0.3.1rc8, which provides /usr/include/dal/file.h instead of /usr/include/dal/file_dal.h and thus causes the build failure. I've checked the two files and, as you'd expect, they're different - the filename change is due to an API change (function names change eg from 'file_dal_open' to 'file_open'). Things are fine in Debian because they only provide the 0.3.0.x versions. I can replicate the build failure by installing sys-fs/progsreiserfs then attempting to install app-emulation/xen-tools. After uninstalling sys-fs/progsreiserfs, app-emulation/xen-tools builds fine. However, I don't have access to hardware with virtualization extensions, so can't test pygrub's functionality - I assume it will be missing support for reading partitions formatted as reiserfs. An easy solution is to make sys-fs/progsreiserfs-0.3.1 block app-emulation/xen-tools, but that's not particularly nice for users. A slightly better approach might be explicitly disabling reiserfs support in pygrub (which may require a patch to setup.py), and using ewarn to notify the user (to prevent bug reports about missing resierfs functionality). I think the ideal solution is an investigation of the API change between 0.3.0 and 0.3.1, and hopefully a backwards-compatible patch to http://lxr.xensource.com/lxr/source/tools/pygrub/src/fsys/reiser/reisermodule.c that allows it to function with either version. However, I'm not in a position to provide this. A more realistic solution would be the introduction of an ebuild for the 0.3.0 series of progsreiserfs, using the same libraries/headers-only approach of the 0.3.1rc8 ebuild.
Created attachment 94557 [details, diff] a patch for reisermodules a patch to test
Hi I just posted a patch that at least compiles xen. Please test if it is also does what it should do.
hmm i really understand nothing... is it a patch for xen or xen-tools? how could i do this correctly, please? (In reply to comment #4) > Hi I just posted a patch that at least compiles xen. Please test if it is also > does what it should do. >
oki, it works with the patch. thank you
Fixed in app-emulation/xen-tools-3.0.2-r4, thanks.