Package Details: xen 4.19.1pre-1

Git Clone URL: https://aur.archlinux.org/xen.git (read-only, click to copy)
Package Base: xen
Description: Open-source type-1 or baremetal hypervisor
Upstream URL: https://xenproject.org/
Keywords: hypervisor virtualization xen
Licenses: GPL2
Submitter: sergej
Maintainer: Refutationalist
Last Packager: Refutationalist
Votes: 185
Popularity: 0.67
First Submitted: 2009-11-09 11:22 (UTC)
Last Updated: 2024-09-20 00:31 (UTC)

Dependencies (63)

Sources (7)

Pinned Comments

Refutationalist commented on 2024-05-22 22:08 (UTC) (edited on 2024-05-23 00:07 (UTC) by Refutationalist)

As of now (2024-22-05) Xen with stubdom doesn't build because of a problem in the imported code. Been this way for about two weeks. Anyone else seeing this behavior?

Also, there is a lot of work happening on Xen in my development repo, thanks to @Serus. Check it out at: https://github.com/refutationalist/saur

Latest Comments

« First ‹ Previous 1 .. 32 33 34 35 36 37 38 39 40 41 42 .. 101 Next › Last »

piwwo commented on 2015-07-10 11:24 (UTC)

@kantras Unfortunately I don't know which log there are alot config.logs and I am not sure which one belongs to the module: xen]$ find ./ -name "config.log" find: `./pkg': Permission denied ./src/xen-4.5.1/config.log ./src/xen-4.5.1/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/doc/config.log ./src/xen-4.5.1/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/libm/config.log ./src/xen-4.5.1/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/libm/machine/config.log ./src/xen-4.5.1/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/config.log ./src/xen-4.5.1/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/libc/sys/config.log ./src/xen-4.5.1/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/libc/config.log ./src/xen-4.5.1/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/libc/machine/config.log ./src/xen-4.5.1/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/libc/machine/x86_64/config.log ./src/xen-4.5.1/stubdom/newlib-x86_64/x86_64-xen-elf/libgloss/doc/config.log ./src/xen-4.5.1/stubdom/newlib-x86_64/x86_64-xen-elf/libgloss/libnosys/config.log ./src/xen-4.5.1/stubdom/newlib-x86_64/x86_64-xen-elf/libgloss/config.log ./src/xen-4.5.1/stubdom/newlib-x86_64/etc/config.log ./src/xen-4.5.1/stubdom/newlib-x86_64/config.log ./src/xen-4.5.1/stubdom/config.log ./src/xen-4.5.1/stubdom/newlib-x86_32/config.log ./src/xen-4.5.1/stubdom/gmp-x86_64/config.log ./src/xen-4.5.1/tools/config.log ./src/xen-4.5.1/tools/qemu-xen-dir/config.log

kantras commented on 2015-07-10 07:00 (UTC)

@piwwo: Still trying to reproduce this; do you also have a copy of the config.log file mentioned in the error message?

piwwo commented on 2015-07-07 16:50 (UTC)

Compiling fails for me make[2]: Leaving directory '/home/xenuser/xen/src/xen-4.5.1/extras/mini-os' touch mk-headers-x86_32 mkdir -p newlib-x86_32 ( cd newlib-x86_32 && \ CC_FOR_TARGET="gcc -isystem /home/xenuser/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC -isystem /home/xenuser/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include/posix -isystem /home/xenuser/xen/src/xen-4.5.1/stubdom/../tools/xenstore/include -isystem /home/xenuser/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include/x86 -isystem /home/xenuser/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include/x86/x86_32 -U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem /home/xenuser/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include/posix -isystem /home/xenuser/xen/src/xen-4.5.1/stubdom/cross-root-i686/i686-xen-elf/include -isystem /usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/include -isystem /home/xenuser/xen/src/xen-4.5.1/stubdom/lwip-x86_32/src/include -isystem /home/xenuser/xen/src/xen-4.5.1/stubdom/lwip-x86_32/src/include/ipv4 -I/home/xenuser/xen/src/xen-4.5.1/stubdom/include -I/home/xenuser/xen/src/xen-4.5.1/stubdom/../xen/include -fno-caller-saves -O2 -fomit-frame-pointer -m64 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O1 -fno-omit-frame-pointer -m32 -march=i686 -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -fno-stack-protector -fno-exceptions -D_I386MACH_ALLOW_HW_INTERRUPTS" AR_FOR_TARGET=ar LD_FOR_TARGET=ld RANLIB_FOR_TARGET=ranlib ../newlib-1.16.0/configure --prefix=/home/xenuser/xen/src/xen-4.5.1/stubdom/cross-root-i686 --verbose --target=i686-xen-elf --enable-newlib-io-long-long --disable-multilib && \ make DESTDIR= && \ make DESTDIR= install ) checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... i686-xen-elf checking for a BSD-compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. Makefile:83: recipe for target 'cross-root-i686/i686-xen-elf/lib/libc.a' failed make[1]: *** [cross-root-i686/i686-xen-elf/lib/libc.a] Error 77 make[1]: Leaving directory '/home/xenuser/xen/src/xen-4.5.1/stubdom' Makefile:73: recipe for target 'install-stubdom' failed make: *** [install-stubdom] Error 2 xen]$ uname -a Linux dom0.xen 4.0.7-2-ARCH #1 SMP PREEMPT Tue Jun 30 07:50:21 UTC 2015 x86_64 GNU/Linux

kantras commented on 2015-07-04 23:47 (UTC)

Updated to 4.5.1 + added some fixes for GCC 5. Note: OVMF is not enabled by default in this build as it still requires some patching before it will support GCC 5.

cyberxndr commented on 2015-06-25 21:22 (UTC)

After a couple of hours I got two successfull builds with different CRC. The first package raises dom0 crush, the second was OK. I don't remember the difference between compilation process. Maybe I forgot to apply patch #6 in first build. Patches #2 #3 #4 didn't work well in the PKGBUILD, so I manualy applied them one by one after each iteration of failed "makepkg -ei". At this moment I able to login into the dom0.

mks commented on 2015-06-24 09:21 (UTC)

apparently you can't search 'xen' in the new home i.e. aur4.archlinux.org. any ideas when to expect upstream fix for gcc5 + Xen 4.4/4.5? thanks

PZB1000 commented on 2015-06-24 05:56 (UTC)

Also just tried to build this package. As the option Werror is used i have got an error in symbols.c "arrary subscript is above array bounds" in line 23 from project src/xen-4.5.0/xen/common. gcc Version 5.1 on arch linux 64 bit

pgmillon commented on 2015-06-21 17:40 (UTC)

Just tried to build on a 32bits system: Version: rel-1.7.5-0-ge51488c-20150621_142420-test-dantooine Fixed space: 0xe05b-0x10000 total: 8101 slack: 10 Percent slack: 0.1% 16bit size: 35488 32bit segmented size: 2208 32bit flat size: 22048 32bit flat init size: 68896 Lowmem size: 2160 f-segment var size: 1728 Linking out/rom16.o out/code16.o: In function `kbd_command': /tmp/yaourt-tmp-ishtanzar/aur-xen/src/xen-4.5.0/tools/firmware/seabios-dir-remote/src/kbd.c:120: undefined reference to `usb_kbd_command' out/code16.o: In function `mouse_command': /tmp/yaourt-tmp-ishtanzar/aur-xen/src/xen-4.5.0/tools/firmware/seabios-dir-remote/src/mouse.c:30: undefined reference to `usb_mouse_command' Makefile:170: recipe for target 'out/rom16.o' failed make[6]: *** [out/rom16.o] Error 1 Linux test-dantooine 4.0.5-1-ARCH #1 SMP PREEMPT Sat Jun 6 18:52:28 CEST 2015 i686 GNU/Linux

maximevince commented on 2015-06-16 08:23 (UTC)

As posted on the old aur: I can confirm the -fno-caller-saves is a valid workaround. My xen-4.5 build now actually boots my arch kernel. I thought it was a macbook/efi issue, but it was actually caused by gcc5! Patch is here: http://pastebin.com/XDpzbLYa So the full set of patches is: http://pastebin.com/Z5BnzFwc http://pastebin.com/19tb2esC http://pastebin.com/WwxugrRi http://pastebin.com/7742EHd1 http://pastebin.com/aNWdhEH0 http://pastebin.com/XDpzbLYa

ArthurBorsboom commented on 2015-05-31 08:56 (UTC)

From the same thread, apparently a workaround is setting the following compile flag avoiding the bug. fno-caller-saves As long as the bug is present, maybe it is an idea to implement this flag into the PKGBUILD?