Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 351648 - app-emulation/xen-tools incorrectly masks USE=hvm for no-multilib profile
Summary: app-emulation/xen-tools incorrectly masks USE=hvm for no-multilib profile
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: AMD64 Linux
: High minor with 1 vote (vote)
Assignee: Gentoo Xen Devs
URL:
Whiteboard:
Keywords:
Depends on: gcc-4.6-stable
Blocks:
  Show dependency tree
 
Reported: 2011-01-14 13:49 UTC by Spooky Ghost
Modified: 2014-05-30 10:35 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Fixes for amd64/no-multilib xen-tools[hvm] ebuild (xen-tools-4.2.1-r2.ebuild.diff,1006 bytes, patch)
2013-02-18 13:24 UTC, Zoltán Halassy
Details | Diff
working no-multilib hvm patch for xen-tools-4.4.0-r4.ebuild (xen-tools-4.4.0-r4.ebuild.diff,1.52 KB, patch)
2014-05-28 12:08 UTC, Zoltán Halassy
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Spooky Ghost 2011-01-14 13:49:37 UTC
USE=hvm was previously masked on amd64 no-multilib as it had dependencies on a 32-bit environment to build tools.  This no longer seems to be the case.  I have removed the mask from the profile and built xen-tools with its hvm dependencies and started hvm domUs.

# eselect profile show
Current make.profile symlink:
  default/linux/amd64/10.0/no-multilib

Please remove the USE=hvm profile masks for xen-tools or only mask for older versions of xen-tools.

The .ebuild also has its own check for amd64 && USE=hvm which needs to be removed.


Reproducible: Always




Created hvm domU using livecd images from Ubuntu 10.10 and Fedora 14
Comment 1 Spooky Ghost 2011-05-12 16:01:45 UTC
I have checked and found xen-tools-4.1.0-r1 is the same.  With the following patch to the ebuild and "find /usr/portage/profiles -type f | xargs grep -l ^hvm | xargs sed -i -e 's/^hvm/#hvm/'" my 32-bit HVM domUs are still working just fine.  The rm -rf was needed since the build was bugging out as the directory didn't exist.

--- /usr/portage/app-emulation/xen-tools/xen-tools-4.1.0-r1.ebuild      2011-04-05 22:31:03.000000000 +0100
+++ xen-tools-4.1.0-r2.ebuild   2011-05-10 17:25:27.626179027 +0100
@@ -64,12 +64,12 @@
                export "CONFIG_IOEMU=n"
        fi

-       if ! use x86 && ! has x86 $(get_all_abis) && use hvm; then
-               eerror "HVM (VT-x and AMD-v) cannot be built on this system. An x86 or"
-               eerror "an amd64 multilib profile is required. Remove the hvm use flag"
-               eerror "to build xen-tools on your current profile."
-               die "USE=hvm is unsupported on this system."
-       fi
+       #if ! use x86 && ! has x86 $(get_all_abis) && use hvm; then
+       #       eerror "HVM (VT-x and AMD-v) cannot be built on this system. An x86 or"
+       #       eerror "an amd64 multilib profile is required. Remove the hvm use flag"
+       #       eerror "to build xen-tools on your current profile."
+       #       die "USE=hvm is unsupported on this system."
+       #fi

        if [[ -z ${XEN_TARGET_ARCH} ]] ; then
                if use x86 && use amd64; then
@@ -177,7 +177,7 @@
                || die "install failed"

        # Remove RedHat-specific stuff
-       rm -r "${D}"/etc/default "${D}"/etc/init.d/xen* || die
+       rm -rf "${D}"/etc/default "${D}"/etc/init.d/xen* || die

        dodoc README docs/README.xen-bugtool docs/ChangeLog
        if use doc; then
Comment 2 Zoltán Halassy 2011-08-25 08:22:55 UTC
Hm. Actually what I did with my no-multilib profile, is to compile xen-tools without hvm USE flag on the target machine, then compiled xen-tools on a different machine with multilib profile and hvm USE flag, then just copied the hvmloader to my no-multilib profile comp. This one works aswell. My proposal would be to create a hvmloader-bin package. But then it seems it's even possibl to compile the hvmloader itself with no-multilib profile, so that would be definitely better solution.
Comment 3 Spooky Ghost 2011-11-03 18:20:51 UTC
Since 4.1.1-r6 and 4.1.2 my original trick to unmask hvm and compile no longer works and errors with:

make[1]: Entering directory `/var/tmp/portage/app-emulation/xen-tools-4.1.1-r6/work/xen-4.1.1/tools'
make -C firmware all
make[2]: Entering directory `/var/tmp/portage/app-emulation/xen-tools-4.1.1-r6/work/xen-4.1.1/tools/
firmware'
make subdirs-all; \

make[3]: Entering directory `/var/tmp/portage/app-emulation/xen-tools-4.1.1-r6/work/xen-4.1.1/tools/
firmware'
make[4]: Entering directory `/var/tmp/portage/app-emulation/xen-tools-4.1.1-r6/work/xen-4.1.1/tools/
firmware'
make -C rombios all
make[5]: Entering directory `/var/tmp/portage/app-emulation/xen-tools-4.1.1-r6/work/xen-4.1.1/tools/
firmware/rombios'
make[6]: Entering directory `/var/tmp/portage/app-emulation/xen-tools-4.1.1-r6/work/xen-4.1.1/tools/
firmware/rombios'
make -C 32bit all
make[7]: Entering directory `/var/tmp/portage/app-emulation/xen-tools-4.1.1-r6/work/xen-4.1.1/tools/
firmware/rombios/32bit'
make[8]: Entering directory `/var/tmp/portage/app-emulation/xen-tools-4.1.1-r6/work/xen-4.1.1/tools/
firmware/rombios/32bit'
make -C tcgbios all
make[9]: Entering directory `/var/tmp/portage/app-emulation/xen-tools-4.1.1-r6/work/xen-4.1.1/tools/
firmware/rombios/32bit/tcgbios'
x86_64-pc-linux-gnu-gcc   -O2 -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing -std=gnu99
-Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement  -D__XEN_TOOLS__ -MMD -MF .tcgbi
os.o.d  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -DNDEBUG -Werror -fno-sta
ck-protector -fno-exceptions -fno-builtin -msoft-float -I../../../../../tools/include -I.. -I../.. -
c -o tcgbios.o tcgbios.c
x86_64-pc-linux-gnu-gcc   -O2 -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing -std=gnu99
-Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement  -D__XEN_TOOLS__ -MMD -MF .tpm_d
rivers.o.d  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -DNDEBUG -Werror -fno
-stack-protector -fno-exceptions -fno-builtin -msoft-float -I../../../../../tools/include -I.. -I../
.. -c -o tpm_drivers.o tpm_drivers.c
In file included from /usr/include/features.h:380:0,
                 from /usr/include/stdint.h:26,
                 from /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/stdint.h:3,
                 from ../rombios_compat.h:8,
                 from tcgbios.c:24:
/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
compilation terminated.

I copied a stubs-32.h from a multilib system to /usr/include/gnu/ and this allowed the compilation to complete.  No errors observed with 32/64 bit hvm machines booted from Ubuntu 10.10 .iso images.
Comment 4 Ian Delaney (RETIRED) gentoo-dev 2011-11-08 15:32:02 UTC
hmmmm, maybe for you

idella5@nonmulti ~/documents $ cat /etc/portage/profile/package.use.mask 
app-emulation/xen-tools -hvm

idella5@nonmulti ~/documents $ eix xen-tools
[U] app-emulation/xen-tools
     Available versions:  3.4.2-r3 (~)3.4.2-r5 (~)4.1.1-r5 4.1.1-r6 (~)4.1.2!t **9999 {acm api custom-cflags debug doc flask hvm ioemu pygrub qemu screen xend}
     Installed versions:  4.1.1-r6(23:06:36 08/11/11)(api flask hvm pygrub qemu screen xend -custom-cflags -debug -doc)

nonmulti xen-tools # xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  6980     4     r-----   2101.9
fed14                                        5   600     2     -b----     50.1
fedora9                                          600     2                 0.0

idella5@nonmulti ~/documents $ cat /mnt/images/xen/images/fedora/fedora9/fedora9.txt 
System is 32 bit, para-virt
user is idella

idella5@nonmulti ~/documents $ cat /mnt/images/xen/images/fedora/fedora14/fed14.txt
root passwd=**********
idella passwd=**********
arch=x86

nonmulti xen-tools # xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  7375     4     r-----   2290.4
fed14                                        5   600     2     -b----     52.5
fedora9                                      6   600     2     -b----      9.2

<domain type='xen' id='5'>
  <name>fed14</name>

    <type>hvm</type>
    <loader>/usr/lib/xen/boot/hvmloader</loader>
    <kernel></kernel>

This proves your point.  hvm unmasked, xen-tools emerged with use hvm, 2 fedora started; 1 paravirt x86, 1 booted hvmloader.  The lines were commented out in the ebuild of -4.1.1-r6.  Shall see to this being implemented.
Comment 5 Ian Delaney (RETIRED) gentoo-dev 2011-11-08 16:13:17 UTC
Spooky,

submit your emerge --info, got to see what you're missing
Comment 6 Magnus Granberg gentoo-dev 2011-11-08 19:20:12 UTC
[ebuild   R    ] app-emulation/xen-tools-4.1.1-r6  USE="hvm qemu -api -custom-cflags -debug -doc -flask -pygrub -screen -xend" 0 kB
....
emerge --info
Portage 2.1.10.11 (hardened/linux/amd64/no-multilib, gcc-4.4.5, glibc-2.12.2-r0, 3.0.4-hardened-r1 x86_64)
=================================================================
System uname: Linux-3.0.4-hardened-r1-x86_64-Intel-R-_Xeon-R-_CPU_E5420_@_2.50GHz-with-gentoo-2.0.3
Timestamp of tree: Tue, 08 Nov 2011 16:45:01 +0000
app-shells/bash:          4.1_p9
dev-lang/python:          2.7.1-r1, 3.1.3-r1
dev-util/pkgconfig:       0.26
sys-apps/baselayout:      2.0.3
sys-apps/openrc:          0.8.3-r1
sys-apps/sandbox:         2.4
sys-devel/autoconf:       2.68
sys-devel/automake:       1.11.1
sys-devel/binutils:       2.21.1-r1
sys-devel/gcc:            4.4.5
sys-devel/gcc-config:     1.4.1-r1
sys-devel/libtool:        2.4-r1
sys-devel/make:           3.82-r1
sys-kernel/linux-headers: 2.6.36.1 (virtual/os-headers)
sys-libs/glibc:           2.12.2
Repositories: gentoo
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe -march=core2"
CHOST="x86_64-pc-linux-gnu"
Comment 7 Spooky Ghost 2011-11-08 21:07:18 UTC
# eix app-emulation/xen-tools
[I] app-emulation/xen-tools
     Available versions:  3.4.2-r3 (~)3.4.2-r5 (~)4.1.1-r5 4.1.1-r6 (~)4.1.2!t **9999 {acm api custom-cflags debug doc flask hvm ioemu pygrub qemu screen xend}
     Installed versions:  4.1.2(20:04:45 02/11/11)(doc hvm pygrub qemu xend -api -custom-cflags -debug -flask -screen)
     Homepage:            http://xen.org/
     Description:         Xend daemon and tools
Comment 8 Spooky Ghost 2011-11-08 21:10:07 UTC
# emerge --info
Portage 2.1.10.11 (default/linux/amd64/10.0/no-multilib, gcc-4.5.3, glibc-2.12.2-r0, 3.0.8 x86_64)
=================================================================
System uname: Linux-3.0.8-x86_64-Six-Core_AMD_Opteron-tm-_Processor_2423_HE-with-gentoo-2.0.3
Timestamp of tree: Tue, 08 Nov 2011 17:15:01 +0000
ccache version 3.1.4 [enabled]
app-shells/bash:          4.1_p9
dev-java/java-config:     1.3.7-r1, 2.1.11-r3
dev-lang/python:          2.4.6, 2.5.4-r4, 2.6.6-r2, 2.7.2-r3, 3.1.4-r3
dev-util/ccache:          3.1.4
dev-util/cmake:           2.8.4-r1
dev-util/pkgconfig:       0.26
sys-apps/baselayout:      2.0.3
sys-apps/openrc:          0.8.3-r1
sys-apps/sandbox:         2.4
sys-devel/autoconf:       2.13::<unknown repository>, 2.68
sys-devel/automake:       1.4_p6::<unknown repository>, 1.5::<unknown repository>, 1.6.3::<unknown repository>, 1.7.9-r1::<unknown repository>, 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1
sys-devel/binutils:       2.21.1-r1
sys-devel/gcc:            4.3.4, 4.4.5, 4.5.3-r1
sys-devel/gcc-config:     1.4.1-r1
sys-devel/libtool:        2.4-r1
sys-devel/make:           3.82-r1
sys-kernel/linux-headers: 2.6.39 (virtual/os-headers)
sys-libs/glibc:           2.12.2
Repositories: gentoo x-portage
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=amdfam10 -O3 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /var/bind"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-march=amdfam10 -O3 -pipe"
DISTDIR="/misc/distfiles"
EMERGE_DEFAULT_OPTS="--with-bdeps y"
FEATURES="assume-digests binpkg-logs ccache distlocks ebuild-locks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
FFLAGS=""
GENTOO_MIRRORS="http://gentoo.virginmedia.com http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo"
LANG="en_GB.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j4"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_EXTRA_OPTS="--progress --stats"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="3dnow X Xaw3d aac aalib acl acpi aim alsa amd64 apache2 audiofile avi bash-completion berkdb bluetooth bmp bonobo bzip2 caps cdb cdr cjk cli consolekit cpdflib cracklib crypt cups curl cxx dba dbm dbus dga directfb divx4linux doc dri dts dvb dvd dvdr encode esd exif expat fam fbcon fftw flac flash foomaticdb fortran ftp gd gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml iconv icq imagemagick imap imlib innodb ipv6 irmc jabber jadetex java jbig joystick jpeg jpeg2k kde kerberos lcms ldap libedit libwww lirc lm_sensors mad maildir mailwrapper mhash mime ming mmx mng modules mp3 mpeg msn mudflap mysql ncurses nls nptl nptlonly offensive ogg openal opengl openmp oscar pam pcre pdf pdflib perl php png policykit postgres ppds pppd pulseaudio python qt4 quicktime readline samba sasl sdl seamonkey semantic-desktop session slp snmp spell sse sse2 ssl svg sysfs tcl tcltk tcpd tetex theora tiff tk truetype unicode usb v4l2 videos vorbis wmf xattr xine xinerama xml xml2 xorg xpm xsl xv xvid yahoo zlib" ALSA_CARDS="emu10k1 intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan stage tables krita karbon braindump" CAMERAS="canon" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev keyboard joystick mouse vmmouse" KERNEL="linux" LCD_DEVICES="mtxorb xosd text ncurses" LIRC_DEVICES="hauppauge" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev vesa vga intel nv nvidia mga r128 radeon vmware v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS
Comment 9 Spooky Ghost 2011-11-08 21:17:11 UTC
I emerged 4.1.2 using version 1.1 of the ebuild.  It has been revised and is now version 1.2 which I have not checked.  Still no problems running Windows XP or 32-bit Linux hvm on my machine.
Comment 10 Ian Delaney (RETIRED) gentoo-dev 2011-11-09 05:21:33 UTC
Never mind about running the vms for now.  We are trying to figure what is missing from your setup that prevents effective compilation of xen-tools with use hvm.  The planting of stub-32.h into your system is a cheat, at best a workaround, not one that offers a clean resolution.  A non multilib system by its nature has no stub-32.h.  Your system not compiling blocks any chance of the use flag being unmasked.  You need to return to a finding a setup that does compile with use hvm and creates the hvmloader.  

My only guess is it may require the presence of another use flag, the inclusion of which see the build process bypass the need for the stubs-32.h.
Juggle your use flags, re-emerge xen-tools.  Start with selecting api,

idella5@nonmulti ~ $ eix xen

[U] app-emulation/xen-tools
     Available versions:  3.4.2-r3 (~)3.4.2-r5 (~)4.1.1-r5 4.1.1-r6 (~)4.1.2!t **9999 {acm api custom-cflags debug doc flask hvm ioemu pygrub qemu screen xend}
     Installed versions:  4.1.1-r6(23:06:36 08/11/11)(api flask hvm pygrub qemu screen xend -custom-cflags -debug -doc).

In gentoo dev land there is a paucity of non multil systems to test on.  Make the most of yours.
Comment 11 Ian Delaney (RETIRED) gentoo-dev 2011-11-09 06:37:10 UTC
This

x86_64-pc-linux-gnu-gcc -O2 -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing -std=gnu99 -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .tcgbios.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -DNDEBUG -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I../../../../../tools/include -I.. -I../.. -c -o tcgbios.o tcgbios.c

is the point where your build fails. Word for word, letter for letter, it matches the same line in my build which happily makes cgbios.o.

nonmulti tcgbios # x86_64-pc-linux-gnu-gcc -O2 -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing -std=gnu99 -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .tcgbios.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -DNDEBUG -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I../../../../../tools/include -I.. -I../.. -c -o tcgbios.o tcgbios.c

nonmulti tcgbios #  ls -ld tcgbios.o
-rw-r--r-- 1 root root 9624 Nov  9 14:30 tcgbios.o

Your build config should NOT go looking for a header that is not meant to be there.  Given yhe version of glibc is not critical, the difference is clearly in the config phase in your setup, nd that is impacted by your use flag selections.  If you wish. post the config log
Comment 12 Ian Delaney (RETIRED) gentoo-dev 2011-11-10 18:48:07 UTC
It will not compile bios files, since they are 32bit only.
Without them it shouldn't work.
Comment 13 Spooky Ghost 2011-12-07 10:52:16 UTC
During the compilation of tcgbios.c includes gnu/stubs.h via the stdinclude features.h. stubs.h in turn includes either stubs-32.h or stubs-64.h depending on the word size, I assume that is conditional on passing -m32 or -m64 to gcc.  The comment in features.h:
/* This is here only because every header file already includes this one.
   Get the definitions of all the appropriate `__stub_FUNCTION' symbols.
   <gnu/stubs.h> contains `#define __stub_FUNCTION' when FUNCTION is a stub
   that will always return failure (and set errno to ENOSYS).  */
#include <gnu/stubs.h>

On a non-multilib platform gcc seems to happily generate 32-bit code providing that there are no library dependencies, e.g.

$ cat counter.c 
#include <features.h> /* line only present when not -nostdinc */

extern int
main(int argc, char *argv[])
{
     int a, i;

     for(i = 0; i < 1000; i++) {
          a = 0;
     }

     i = a;

     return(0);
}
$ # With nostdinc
$ gcc -Wall -m32 -nostdinc  -c counter.c -o counter.o
$ file counter.o
counter.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
$ md5sum counter.o
84f549caa6de4c6b2abfb0e0d6d99a9a  counter.o

$ # Allowing stdinc, empty stubs-32.h present.
$ rm counter.o
$ gcc -Wall -m32 -c counter.c -o counter.o
$ file counter.o
counter.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
$ md5sum counter.o
84f549caa6de4c6b2abfb0e0d6d99a9a  counter.o

$ # No stubs-32.h
$ rm counter.o
$ gcc -Wall -m32 -c counter.c -o counter.o
In file included from /usr/include/features.h:381:0,
                 from counter.c:1:
/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
compilation terminated.


While not an expert on glibc I understand that stubs.h is a way to make certain functions fail because they are deprecated or not implemented.  If the original source code doesn't actually rely on any of these or any other glibc library calls then I think it should compile successfully on multi and not-multi lib systems.  In the case that a non-multilib glibc is compiled I think an empty (i.e. no #define __stub_xxxxs) stubs-32.h file should be installed.  In my tests this empty stubs-32.h allows xen-tools to be compiled and still do not have any problems with my HVM virtual machines.  I believe that this is the case because it is BIOS emulation code which is fully standalone code and does not require being linked with any 32-bit library.  Ultimately I think any change would have to be with glibc to always provide stubs-32.h and not xen.
Comment 14 Ian Delaney (RETIRED) gentoo-dev 2011-12-09 16:59:53 UTC
from the dev; gcc-4.6.2 will be multiarch by default
We can unmask hvm on no-multilib when gcc-4.6.2 will become stable.
So your input results in the request to unmask hvm to be implemented in the future on the stabilisation of gcc-4.6.2.
Comment 15 Zoltán Halassy 2013-01-08 11:21:16 UTC
Could we add something to the ebuild then, like (pseudo code):

if (hvm && amd64 && no-multilib){
 depend >=gcc-4.6.2
}

instead of the masking of the use flag? gcc-4.6.3 stabilization started on january 7-8 2013, so this could happen parallel.
Comment 16 Zoltán Halassy 2013-01-09 12:32:07 UTC
(In reply to comment #14)
> We can unmask hvm on no-multilib when gcc-4.6.2 will become stable.

It seems it's not that easy (or did I miss something?). The problem described in comment #13 still applies with gcc-4.6.3:

[...]
make[9]: Entering directory `/var/tmp/portage/app-emulation/xen-tools-4.2.0-r2/work/xen-4.2.0/tools/firmware/rombios/32bit/tcgbios'
x86_64-pc-linux-gnu-gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable   -D__XEN_TOOLS__ -MMD -MF .tcgbios.o.d  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs   -nopie -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/var/tmp/portage/app-emulation/xen-tools-4.2.0-r2/work/xen-4.2.0/tools/firmware/rombios/32bit/tcgbios/../../../../../tools/include -I.. -I../..  -c -o tcgbios.o tcgbios.c 
In file included from /usr/include/features.h:382:0,
                 from /usr/include/stdint.h:26,
                 from /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/stdint.h:3,
                 from ../../../hvmloader/acpi/acpi2_0.h:21,
                 from ../util.h:4,
                 from tcgbios.c:27:
/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: Nincs ilyen fájl vagy könyvtár
compilation terminated.
make[9]: *** [tcgbios.o] Error 1
make[9]: Leaving directory `/var/tmp/portage/app-emulation/xen-tools-4.2.0-r2/work/xen-4.2.0/tools/firmware/rombios/32bit/tcgbios'
[...]

$ gcc --version
gcc (Gentoo Hardened 4.6.3 p1.9, pie-0.5.2) 4.6.3
[...]
Comment 17 Spooky Ghost 2013-01-09 13:48:50 UTC
In my opinion this was never a gcc issue but a glibc one.  In the case that the profile is no-multilib then glibc should still install a stubs-32.h file as no-multilib does not preclude the capability of the toolchain from building 32-bit code.
Comment 18 Zoltán Halassy 2013-01-09 15:47:16 UTC
> the profile is no-multilib then glibc should still install a stubs-32.h file

The only thing now which prevents the compile is the missing stubs-32.h . Manually copying the file from a multilib system makes it work.

We could either request the glibc ebuild maintainers to install the stubs-32.h file, or the xen-tools package could provide the stubs-32.h for itself.

The file starts with a comment about the file is automatically generated. I don't know if supplying a static stubs-32.h would work (either with definitions in place) or empty (does the hvmloader compile need the definitions there?).

If the static (even if empty) solution works, then I don't think the glibc ebuild needs modification.
Comment 19 Ian Delaney (RETIRED) gentoo-dev 2013-01-23 12:34:48 UTC
ok I'll attempt to inquire
Comment 20 Ian Delaney (RETIRED) gentoo-dev 2013-02-11 09:55:31 UTC
Spooky Ghost, Zoltán Halassy.

Well done for your diligent pursuit of xen over at least 18 months now. This old bug is about due to be cleaned up.

(In reply to comment #17)
> In my opinion this was never a gcc issue but a glibc one.  In the case that
> the profile is no-multilib then glibc should still install a stubs-32.h file
> as no-multilib does not preclude the capability of the toolchain from
> building 32-bit code.

This appears to be the ultimate solution.  However, now that I'm dev and seemingly the only 1 inclined to support the interests of users the likes of yourself, I can get there in 2 stages .

(In reply to comment #18)
> The only thing now which prevents the compile is the missing stubs-32.h .
> Manually copying the file from a multilib system makes it work.
> 
> We could either request the glibc ebuild maintainers to install the
> stubs-32.h file, or the xen-tools package could provide the stubs-32.h for
> itself.

The latter 
The former requires a double dose of co-operation and approval, namely by the toolchain herd . For now I have done the latter.  In the long term it isn't a viable fix, since it's a system file and will be a moving target, unless it's an empty stub purely for the purpose of appeasing the build.

See xen-tools-4.2.1-r2
Note:
use hvm && cp -r "${FILESDIR}"/stubs-32.h xen/tools/include && einfo "stubs-32.h added" || die

test, try out, post.
Comment 21 Akos Szalkai 2013-02-11 16:06:33 UTC
> use hvm && cp -r "${FILESDIR}"/stubs-32.h xen/tools/include && einfo "stubs-32.h added" || die

This way you cannot build with USE=-hvm.
Comment 22 Ian Delaney (RETIRED) gentoo-dev 2013-02-12 11:44:32 UTC
(In reply to comment #21)
> > use hvm && cp -r "${FILESDIR}"/stubs-32.h xen/tools/include && einfo "stubs-32.h added" || die
> 
> This way you cannot build with USE=-hvm.

It's the quick or the dead with xen.  I fixed it a few hours ago
Comment 23 Ian Delaney (RETIRED) gentoo-dev 2013-02-12 13:40:39 UTC
xen-tools-4.2.1-r2.ebuild is now masked in portage but available in the virtualization overlay.  On reflection adding such a file to source in a portage available ebuild is not a recommendable practice.
Comment 24 Zoltán Halassy 2013-02-18 12:33:11 UTC
please remove the

die "USE=hvm is unsupported on this system."

from the -r2 masked ebuild too, thank you!
Comment 25 Zoltán Halassy 2013-02-18 13:21:14 UTC
There is no include named folder in xen/tools, so cp copies stubs-32.h into a file named "include", into xen/tools, so the build doesn't work. But there is a tools/include folder already (a tools folder with the same level with the xen folder), we could use that one instead.

Another problem is /usr/include/gnu/stubs.h requires "gnu/stubs-32.h", so at first try I did this:

mkdir -p tools/include/gnu || die "mkdir failed"
cp "${FILESDIR}"/stubs-32.h tools/include/gnu || die "cp failed"

But the compilation still fails later, because at some point the following happens:

XEN_TARGET_ARCH=x86_32 make -f blowfish.mk all
make[5]: Entering directory `/var/tmp/portage/app-emulation/xen-tools-4.2.1-r2/work/xen-4.2.1/tools/tests/x86_emulator'
x86_64-pc-linux-gnu-gcc  -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable   -D__XEN_TOOLS__ -MMD -MF .blowfish.bin.d  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -nopie -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -c blowfish.c
In file included from /usr/include/features.h:382:0,
                 from /usr/include/stdint.h:26,
                 from /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/stdint.h:3,
                 from blowfish.c:19:
/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
compilation terminated.

As you can see, there is no -I command line option provided to gcc, so it doesn't know where to find the missing gnu/stubs-32.h file.

My proposal would be the following:

Use the CPATH environment variable, for the extra file, using a newly created extra folder. This would be safe and universal.

Attaching a diff for -r2 which works for me.
Comment 26 Zoltán Halassy 2013-02-18 13:24:42 UTC
Created attachment 339246 [details, diff]
Fixes for amd64/no-multilib xen-tools[hvm] ebuild
Comment 27 Ian Delaney (RETIRED) gentoo-dev 2013-02-20 09:22:38 UTC
I should have entered this probably saving your recent effort.
I have put this to some devs who deal in toolchain related areas, and he is in the process I hope of making  fix reaching beyond the scope you have used.  The key point he makes is that the build is drawing on system installed header files.

As for cp -r "${FILESDIR}"/stubs-32.h xen/tools/include
it should have been cp -r "${FILESDIR}"/stubs-32.h xen/tools/include/
making it copy into the include folder, not a file named include. However the pending fix will over-ride this minor error making it entirely superfluous.
The intent was to copy if to the include folder. You are simply prompting to use the other include folder in /tools.

The pending fix will fundamentally re-write the build to the extent of using local in source header files with the content that it currently draws from -I to system installed headers, and it won't be easy.  The copying of a stubs-32.h itself is over simplistic to the point of opposing basic gentoo protocols.  The file is generated during a glibc build and will therefore be subject to change in future version bumps of glibc.  An ebuild cannot go editing or patching installed system files. Your last submission won't necessarily be wasted, it will be useful for the other devs to peruse and use for consideration. I have CC'd him, ensuring he will get this immediately, and also marks the next point of IN_PROGRESS
Comment 28 Ian Delaney (RETIRED) gentoo-dev 2013-03-08 12:50:09 UTC
progress?
Comment 29 Yixun Lan archtester gentoo-dev 2014-05-27 22:39:04 UTC
ping.. sorry, I kind of lost track of this bug..
(don't have no-multilib system at hand)

so my question, do we still have problem with current xen versions? (4.2.4, 4.3.x..), current stable gcc is 4.7.3-r1
Comment 30 Zoltán Halassy 2014-05-28 11:40:22 UTC
(In reply to Yixun Lan from comment #29)
> so my question, do we still have problem with current xen versions? (4.2.4,
> 4.3.x..), current stable gcc is 4.7.3-r1

Yes.

To sum it up:

- GCC on a no-multilib system *can* compile 32-binaries (the compiled firmware doesn't need to run on the dom0 (so it does neither need 32-bit libraries, nor 32-bit kernel support), it will be executed by the hypervisor)
- hvm USE flag causes to compile firmwares (tools/firmware)
- tools/firmware/hvmloader/acpi/acpi2_0.h includes <stdint.h>
- <stdint.h> includes <features.h>
- <features.h> includes <gnu/stubs.h>
- <gnu/stubs.h> tries to include <gnu/stubs-32.h> on a 32bit system. no-multilib glibc doesn't include this file

If we copy stubs-32.h from a multilib system to /usr/include/gnu the ebuild compiles successfully and the compiled hvmloader works.
If the stubs-32.h is empty (0 bytes), it still compiles, and still works.
The proposed solution was to provide a (filled or empty) stubs-32.h with the ebuild, and make everyone happy.
Comment 31 Zoltán Halassy 2014-05-28 12:08:36 UTC
Created attachment 377760 [details, diff]
working no-multilib hvm patch for xen-tools-4.4.0-r4.ebuild

Attached working patch for 4.4.0-r4
Comment 32 Yixun Lan archtester gentoo-dev 2014-05-30 10:35:22 UTC
+  30 May 2014; Yixun Lan <dlan@gentoo.org> xen-tools-4.2.4-r4.ebuild,
+  xen-tools-4.3.2-r3.ebuild, xen-tools-4.4.0-r5.ebuild:
+  fix hvm buf for no-multilib profile, bug #351648, thanks Zoltán Halassy,
+  Spooky Ghost

fixed without revision bump, thanks all