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?
Search Criteria
Package Details: xen-docs 4.19.1pre-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/xen.git (read-only, click to copy) |
---|---|
Package Base: | xen |
Description: | Xen hypervisor documentation and man pages |
Upstream URL: | https://xenproject.org/ |
Keywords: | hypervisor virtualization xen |
Licenses: | GPL2 |
Submitter: | sergej |
Maintainer: | Refutationalist |
Last Packager: | Refutationalist |
Votes: | 185 |
Popularity: | 0.46 |
First Submitted: | 2009-11-09 11:22 (UTC) |
Last Updated: | 2024-09-20 00:31 (UTC) |
Dependencies (35)
- acpica (make)
- bin86AUR (make)
- bison (byacc-bisonAUR, bison-gitAUR) (make)
- bridge-utils (make)
- dev86AUR (make)
- fig2dev (fig2dev-gitAUR) (make)
- flex (flex-gitAUR) (make)
- gettext (gettext-gitAUR) (make)
- git (git-gitAUR, git-glAUR) (make)
- glib2 (glib2-gitAUR, glib2-selinuxAUR, glib2-patched-thumbnailerAUR) (make)
- gnutls (gnutls-gitAUR) (make)
- inetutils (inetutils-gitAUR, busybox-coreutilsAUR) (make)
- iproute2 (iproute2-gitAUR, busybox-coreutilsAUR, iproute2-selinuxAUR) (make)
- lib32-glibc (lib32-glibc-gitAUR, lib32-glibc-linux4AUR, lib32-glibc-eacAUR, lib32-glibc-eac-binAUR, lib32-glibc-eac-rocoAUR) (make)
- libaio (libaio-gitAUR) (make)
- libuuid.so (util-linux-libs-selinuxAUR, util-linux-libs-aesAUR, lib32-util-linux, util-linux-libs) (make)
- libx11 (libx11-gitAUR) (make)
- lzo (make)
- ncurses (ncurses-gitAUR) (make)
- openssl (openssl-gitAUR, openssl-staticAUR) (make)
- pandoc (pandoc-static-gitAUR, pandoc-sile-gitAUR, pandoc-binAUR, pandoc-cli) (make)
- pciutils (pciutils-gitAUR) (make)
- pixman (pixman-gitAUR) (make)
- pkgconf (pkgconf-gitAUR) (make)
- python (python37AUR, python311AUR, python310AUR) (make)
- sdl2 (sdl2-gitAUR, sdl2-compat-gitAUR) (make)
- systemd (systemd-chromiumosAUR, systemd-selinuxAUR, systemd-gitAUR, systemd-fmlAUR) (make)
- systemd-libs (systemd-chromiumos-libsAUR, systemd-libs-selinuxAUR, systemd-libs-gitAUR, systemd-libs-fmlAUR) (make)
- valgrind (valgrind-gitAUR) (make)
- vde2 (vdeplug4-gitAUR) (make)
- wget (wget-gitAUR, wurlAUR) (make)
- yajl (yajl-gitAUR) (make)
- zlib (zlib-ng-compat-gitAUR, zlib-gitAUR, zlib-ng-compat) (make)
- xen-pvhgrubAUR (optional) – bootloader for PVH domains
- xen-qemuAUR (xen-qemuAUR) (optional) – needed for PV and HVM domUs
Required by (1)
- xen (optional)
Sources (7)
Latest Comments
« First ‹ Previous 1 .. 33 34 35 36 37 38 39 40 41 42 43 .. 101 Next › Last »
ArthurBorsboom commented on 2015-05-31 08:56 (UTC)
jkf commented on 2015-05-30 19:08 (UTC)
After further investigation, it does indeed appear that GCC 5 is mis-compiling Xen.
http://www.gossamer-threads.com/lists/xen/devel/381362#381362
Any one know if GCC 4.9 can co-exist with GCC 5 on the same system? Or would it be easier to roll back to a version of Arch before GCC 5 became the default?
jackb commented on 2015-05-30 05:22 (UTC)
I can add that I believe, based on your description, that I'm experiencing the same issue. After applying the suggested patches I got a clean build, but was unable to boot int the xen dom0. Booting the original Arch kernel worked fine.
jkf commented on 2015-05-29 06:43 (UTC)
Greetings,
Following the comments in this thread, I have successfully built a Xen 4.5.0 package, but it fails during boot when Xen starts the Linux kernel. I have been following the following thread on the xen-devel mailing list which seems to suggest an issue with GCC 5. I have also posted to that thread to get more data to the Xen developers.
http://www.gossamer-threads.com/lists/xen/devel/379916
I am running a system updated just a few days ago, that boots via UEFI and gummiboot. I have a working Xen 4.4.1 package that I built before GCC was upgraded to 5, so I believe this is an issue with Xen itself and not my environment. The system also functions properly when booting the Linux kernel directly. See the link below for the boot log I captured via the serial port.
http://pastebin.com/bBC78306
Thinking my toolchain was the issue, I tried the Xen 4.5.0 EFI binary from Fedora 22, and it failed exactly the same way. It was compiled with GCC 5.0.1. See the below link for the boot log from that binary.
http://pastebin.com/jvg1JazC
Then I found the message linked below and tried the build of 4.5.1-rc1 that a poster did with GCC 4.9.2 on Fedora 21, and it booted successfully. See the boot log below from that.
http://www.gossamer-threads.com/lists/xen/devel/380173#380173
http://pastebin.com/DKxwaU2U
Xen is way lower level in the system that I'm used to digging around, so does anyone else have any thoughts on this issue?
Thanks!
cptG commented on 2015-05-28 10:51 (UTC)
maelask: you'll need to apply the patches posted by djvinz.
Download them and change PKGBUILD to apply them.
The patch called seabios-gcc5.patch won't apply from whithin makepkg since the directory seabios-dir-remote does not exist yet at that moment. Apply this one manually after compilation errors out and issue "makepkg -ei". See my comment below.
maelask commented on 2015-05-27 16:56 (UTC)
Getting this while trying to compile.
symbols.c: In function 'symbols_lookup':
symbols.c:23:61: error: array subscript is above array bounds [-Werror=array-bounds]
#define symbols_address(n) (SYMBOLS_ORIGIN + symbols_offsets[n])
^
symbols.c:128:47: note: in expansion of macro 'symbols_address'
while (low && symbols_address(low - 1) == symbols_address(low))
^
symbols.c:23:61: error: array subscript is above array bounds [-Werror=array-bounds]
#define symbols_address(n) (SYMBOLS_ORIGIN + symbols_offsets[n])
^
symbols.c:136:13: note: in expansion of macro 'symbols_address'
if (symbols_address(i) > symbols_address(low)) {
^
cc1: all warnings being treated as errors
/tmp/yaourt-tmp-maelask/aur-xen/src/xen-4.5.0/xen/Rules.mk:168: recipe for target 'symbols.o' failed
cptG commented on 2015-05-27 10:27 (UTC)
The patch touching seabios-dir-remote can not be applied from within PKGBUILD since that dir does not exist before make is being called. There should be a patch changing ./tools/firmware/Makefile to apply the patch I think.
I just went ahead and patched manually and did "makepkg -ei", still waiting for the build to finish though...
kantras commented on 2015-05-26 04:23 (UTC)
It will be once I've finished testing this, and any other changes that I might want to bring in for the next version
Pinned Comments
Refutationalist commented on 2024-12-06 01:37 (UTC)
Please Note: Per best-practices by upstream this package follows the git stable branch. Minor releases do not require a version bump and the PKGBUILD will provide the appropriate version number.
stubdom is still broken.