Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[solved] chroot corei7->atom movbe illegal instruction
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Installing Gentoo
View previous topic :: View next topic  
Author Message
musv
Advocate
Advocate


Joined: 01 Dec 2002
Posts: 3333
Location: de

PostPosted: Fri Oct 19, 2012 5:08 pm    Post subject: [solved] chroot corei7->atom movbe illegal instruction Reply with quote

Hi there!

Due to architecture problems compiling in a chroot I tried to setup a cross-compiling environment. But compiling fails in many cases by different reasons.

Here is what I did so far:

1. Hardware
Host: Xeon X5650 (x86_46-pc-linux-gnu)
Target: Atom N270 (i686-pc-linux-gnu)

2. Setup the host environment
Installation Cross-Compiler:
USE="gcj gtk mudflap nls objc objc++ objc-gc gd" crossdev -v -t i686-pc-linux-gnu


Then according to Cross Development Manual:
/usr/local/bin/xmerge:
#!/bin/bash
CBUILD=$(portageq envvar CHOST)
PORTAGE_CONFIGROOT="$SYSROOT"
if [[ "$1" == "--root" ]] ; then
    ROOT="$2"
    shift 2
else
    ROOT="$SYSROOT"
fi
export CBUILD PORTAGE_CONFIGROOT ROOT

MAKEOPTS="-j13" emerge $*


/root/.bashrc:
export SYSROOT="/mnt/miniding/"

Instead of keeping all headerfiles on the host, I just tried to mount the root-directory of the target to that mountpoint

3. Mounting the Target
Code:
mount -t nfs4 miniding:/root /mnt/miniding -o intr,noatime,nodiratime,hard,rsize=32768,wsize=32768
mount -o bind /usr/portage /mnt/miniding/usr/portage

So I have the complete access to the target machine.

The profile is set correctly:
la /mnt/miniding/etc/portage/:

lrwxrwxrwx 1 root root   58 15. Okt 10:37 make.profile -> ../../usr/portage/profiles/default/linux/x86/10.0/desktop/


4.1. Errors Gimp
To test that stuff I tried to emerge gimp:
xmerge gimp:

...
./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-default-binary --with-x --disable-silent-rules --with-aa --with-alsa --disable-altivec --with-bzip2 --with-libcurl --with-dbus --without-gvfs --with-webkit --with-libjpeg --without-libjasper --with-libexif --with-lcms --without-gs --enable-mmx --with-libmng --with-poppler --with-libpng --enable-python --enable-mp --enable-sse --with-librsvg --with-libtiff --with-gudev --without-wmf --with-xmc --with-libxpm --without-xvfb-run --enable-gtk-doc --disable-maintainer-mode
configure: loading site script /usr/share/config.site
configure: loading site script /usr/share/crossdev/include/site/linux
configure: loading site script /usr/share/crossdev/include/site/linux-gnu
configure: loading site script /usr/share/crossdev/include/site/i686-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for i686-pc-linux-gnu-strip... i686-pc-linux-gnu-strip
...
checking if Pango is version 1.32.0 or newer... no
checking if Pango is built with a recent fontconfig... no
configure: error:
*** You have a fontconfig >= 2.2.0 installed on your system, but your
*** Pango library is using an older version. This old version is probably in
*** /usr/X11R6. Look at the above output, and note that the result for
*** FONTCONFIG_CFLAGS is not in the result for PANGOCAIRO_CFLAGS, and that
*** there is likely an extra -I line, other than the ones for GLIB,
*** Freetype, and Pango itself. That's where your old fontconfig files are.
*** Rebuild pango, and make sure that it uses the newer fontconfig. The
*** easiest way be sure of this is to simply get rid of the old fontconfig.
*** When you rebuild pango, make sure the result for FONTCONFIG_CFLAGS is
*** the same as the result here.

!!! Please attach the following file when seeking support:
!!! /var/tmp/portage/media-gfx/gimp-2.8.2/work/gimp-2.8.2/config.log
 * ERROR: media-gfx/gimp-2.8.2 failed (configure phase):
 *   econf failed
 *
 * Call stack:
 *          ebuild.sh, line   89:  Called src_configure
 *        environment, line 6051:  Called gnome2_src_configure
 *        environment, line 3245:  Called econf '--enable-default-binary' '--with-x' '--disable-silent-rules' '--with-aa' '--with-alsa' '--disable-altivec' '--with-bzip2' '--with-libcurl' '--with-dbus' '--without-gvfs' '--with-webkit' '--with-libjpeg' '--without-libjasper' '--with-libexif' '--with-lcms' '--without-gs' '--enable-mmx' '--with-libmng' '--with-poppler' '--with-libpng' '--enable-python' '--enable-mp' '--enable-sse' '--with-librsvg' '--with-libtiff' '--with-gudev' '--without-wmf' '--with-xmc' '--with-libxpm' '--without-xvfb-run' '--enable-gtk-doc' '--disable-maintainer-mode'

Installed is fontconfig-2.9.0 on the target machine. And pango is definitely built with that fontconfig version. If I build gimp locally on the target machine that error does not appear.

4.2. error pango
xmerge -1 pango:

...
  CC     libpangocairo_1_0_la-pangocairo-fcfontmap.lo
  CC     querymodules.o
  CCLD   libpango-1.0.la
  CCLD   libpangox-1.0.la
  CCLD   libpangoft2-1.0.la
  GISCAN Pango-1.0.gir
/usr/lib/libfreetype.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make[4]: *** [libpangoft2-1.0.la] error 1


4.3. error glib
xmerge -1 glib:

...
  CC       libgio_2_0_la-gvfs.lo
  CC       libgio_2_0_la-gvolume.lo
  CC       libgio_2_0_la-gvolumemonitor.lo
  CC       libgio_2_0_la-gzlibcompressor.lo
  CC       libgio_2_0_la-gzlibdecompressor.lo
  CC       libgio_2_0_la-gioenumtypes.lo
  CC       libgio_2_0_la-gdesktopappinfo.lo
  CC       libgio_2_0_la-gfiledescriptorbased.lo
  CC       libgio_2_0_la-gunixconnection.lo
gzlibcompressor.c:28:18: fatal error: zlib.h: No such file or directory
compilation terminated.
make[4]: *** [libgio_2_0_la-gzlibcompressor.lo] error 1

zlib.h is installed:
locate zlib.h:
 
/usr/include/bzlib.h
/usr/include/zlib.h
/usr/include/boost-1_49/boost/iostreams/detail/config/zlib.hpp
/usr/include/boost-1_49/boost/iostreams/filter/zlib.hpp
/usr/include/crypto++/zlib.h
/usr/lib/klibc/include/zlib.h
/usr/share/doc/boost-1.49.0-r1/html/libs/iostreams/doc/classes/zlib.html
/usr/share/doc/libxml2-2.8.0-r2/html/html/libxml-xzlib.html
/usr/share/doc/php-docs-20101029-r1/de/php-chunked-xhtml/book.zlib.html
/usr/share/doc/php-docs-20101029-r1/de/php-chunked-xhtml/intro.zlib.html
/usr/share/doc/php-docs-20101029-r1/de/php-chunked-xhtml/ref.zlib.html
/usr/share/doc/php-docs-20101029-r1/pt_BR/php-chunked-xhtml/book.zlib.html
/usr/share/doc/php-docs-20101029-r1/pt_BR/php-chunked-xhtml/intro.zlib.html
/usr/share/doc/php-docs-20101029-r1/pt_BR/php-chunked-xhtml/ref.zlib.html
/usr/share/doc/python-docs-2.7.3/html/library/zlib.html
/usr/share/doc/python-docs-3.2.3/html/library/zlib.html
/usr/share/texmf/tex4ht/ht-fonts/alias/arabi/nazlib.htf
/usr/src/linux-3.3.0-gentoo/include/config/crypto/zlib.h
/usr/src/linux-3.3.0-gentoo/include/config/squashfs/zlib.h
/usr/src/linux-3.3.1-gentoo/include/config/crypto/zlib.h
/usr/src/linux-3.3.1-gentoo/include/config/squashfs/zlib.h
/usr/src/linux-3.3.3-gentoo/include/config/crypto/zlib.h
/usr/src/linux-3.3.3-gentoo/include/config/squashfs/zlib.h
/usr/src/linux-3.4.0-gentoo/include/config/crypto/zlib.h
/usr/src/linux-3.4.0-gentoo/include/config/squashfs/zlib.h
/usr/src/linux-3.4.4-gentoo/include/config/crypto/zlib.h
/usr/src/linux-3.4.4-gentoo/include/config/squashfs/zlib.h
/usr/src/linux-3.4.4-gentoo/include/linux/zlib.h
/usr/src/linux-3.6.2-gentoo/include/linux/zlib.h


equery b zlib.h:

 * Searching for zlib.h ...
dev-libs/crypto++-5.6.1-r3 (/usr/include/crypto++/zlib.h)
dev-libs/klibc-1.5.25 (/usr/lib64/klibc/include/zlib.h)
sys-kernel/gentoo-sources-3.5.4 (/usr/src/linux-3.5.4-gentoo/include/linux/zlib.h)
sys-kernel/gentoo-sources-3.6.2 (/usr/src/linux-3.6.2-gentoo/include/linux/zlib.h)
sys-libs/zlib-1.2.7 (/usr/include/zlib.h)


What's the missing part in my configuration?


Last edited by musv on Tue Nov 06, 2012 9:47 pm; edited 2 times in total
Back to top
View user's profile Send private message
paulj
Guru
Guru


Joined: 30 Sep 2004
Posts: 507
Location: Wales, UK

PostPosted: Fri Oct 19, 2012 5:32 pm    Post subject: Reply with quote

A quick look at the link shows that page as deprecated (last updated in 2006), and points you instead to http://www.gentoo.org/proj/en/base/embedded/handbook/. This information looks different to what I can see in your post, so you might want to give that a go.

Disclaimer: Although I am currently messing around with cross compilers, I haven't yet set up to make a cross compiler work compiling from portage (only my own code for a beaglebone, AVR or arduino), so I can't give you much more advice! I do have an eeePC701 which I want to put Gentoo on (just for the challenge), so I will being going down your path sometime in the future).
[/code]
Back to top
View user's profile Send private message
Randy Andy
Veteran
Veteran


Joined: 19 Jun 2007
Posts: 1148
Location: /dev/koelsch

PostPosted: Fri Oct 19, 2012 5:34 pm    Post subject: Reply with quote

Hi musv.

The Manual you refer to, is marked as deprecated, instead you should follow the first link mentioned under 1. which directs you to the embedded handbook here:
http://www.gentoo.org/proj/en/base/embedded/handbook/
Then choose the chapter for your needs.

Eventually this is also for you (as a german user), if it's not a must for you to cross-compile it locally on a different machine.
http://www.gentoo.org/doc/de/cross-compiling-distcc.xml

Much success, Andy.
[Edit] To slow, overlapping with other post.
_________________
If you want to see a Distro done right, compile it yourself!
Back to top
View user's profile Send private message
musv
Advocate
Advocate


Joined: 01 Dec 2002
Posts: 3333
Location: de

PostPosted: Fri Oct 19, 2012 6:23 pm    Post subject: Reply with quote

Randy Andy wrote:
Eventually this is also for you (as a german user), if it's not a must for you to cross-compile it locally on a different machine.
http://www.gentoo.org/doc/de/cross-compiling-distcc.xml

Distcc is installed but it takes unfortunately much more time. I want avoid distcc for bigger projects. The reason why I need to setup the cross-compiling environment is described here. The hostmachine (corei7) doesn't understand the movbe instruction of the target (atom).


Again to the embedded handbook. I did some changes:

Setting up the environment variables and the cross-compiler links:
Code:
export SYSROOT="/mnt/miniding"
export CBUILD="x86_64-pc-linux-gnu"
export CHOST="i686-pc-linux-gnu"
export PORTAGE_CONFIGROOT="$SYSROOT"
export ROOT="$SYSROOT"
emerge-wrapper --init


The emerge should work now with
Code:
emerge-i686-pc-linux-gnu gimp


The errors are still the same. Something is still missing.
Back to top
View user's profile Send private message
musv
Advocate
Advocate


Joined: 01 Dec 2002
Posts: 3333
Location: de

PostPosted: Mon Oct 29, 2012 10:53 pm    Post subject: Reply with quote

Unfortunately the embedded handbook gave me even less information than the old cross-compile manual.

At least I found some kind of workaround. Again the some facts of the story. All files are from the host-side:
/usr/i686-pc-gnu-linux/etc/portage/make.conf:
source /mnt/miniding/etc/portage/make.conf

CBUILD="x86_64-pc-linux-gnu"
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=atom -O2 -fomit-frame-pointer -pipe"
CXXFLAGS="${CFLAGS}"
ARCH="x86"
ACCEPT_KEYWORDS="~x86"
MAKEOTPS="-j13"
ROOT="/mnt/miniding"
SYSROOT="/mnt/miniding"
#SYSROOT="/usr/i686-pc-linux-gnu"
CTARGET="i686-pc-linux-gnu-pkg-config"
HOSTCC="x86_64-pc-linux-gnu-gcc"
E_MACHINE="EM_386"
PKG_CONFIG_LIBDIR="${ROOT}/usr/lib/pkgconfig"

CONFIG_PROTECT="${ROOT}/etc /usr/share/config ${ROOT}/usr/share/gnupg/qualified.txt"

FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"

# Be sure we dont overwrite pkgs from another repo..
PKGDIR="${ROOT}/packages/"

ELIBC="glibc"

PKG_CONFIG_LIBDIR="${ROOT}/usr/lib/pkgconfig/"
#PORTDIR_OVERLAY="/usr/portage/local/"
PORTDIR="/usr/portage"
DISTDIR="/var/portage/distfiles"
PORTDIR_OVERLAY="/usr/portage/local/local-overlay /usr/portage/local/layman/vdr-devel"


/usr/local/bin/xmerge:
#!/bin/sh
#!/bin/sh
#SYSROOT="/usr/i686-pc-linux-gnu"
#PORTAGE_CONFIGROOT="${SYSROOT}"

SYSROOT="/mnt/miniding"
PORTAGE_CONFIGROOT="/usr/i686-pc-linux-gnu"

ROOT="/mnt/miniding"
#PKG_CONFIG_LIBDIR="${ROOT}/usr/lib/pkgconfig"
#PKG_CONFIG_PATH="${ROOT}/usr/lib/pkgconfig"

export SYSROOT PORTAGE_CONFIGROOT ROOT

export PANGOCAIRO_CFLAGS="-I${ROOT}/usr/include"
export PANGOFT2_CFLAGS="-I${ROOT}/usr/include/"
export PANGOFT2_LIBS="-L${ROOT}/usr/lib/"
export GDK_PIXBUF_CFLAGS="-I${ROOT}/usr/include/"
export GDK_PIXBUF_LIBS="-L${ROOT}/usr/lib/"
export LIBRSVG_CFLAGS="-I${ROOT}/usr/include/"
export LIBRSVG_LIBS="-L${ROOT}/usr/lib/"
export FONTCONFIG_CFLAGS="-I${ROOT}/usr/include/"
export FONTCONFIG_LIBS="-L${ROOT}/usr/lib/"
export FFMPEG_CFLAGS="-I${ROOT}/usr/include/"
export FFMPEG_LIBS="-L${ROOT}/usr/lib/"
export TIFF_CFLAGS="-I${ROOT}/usr/include/"
export TIFF_LIBS="-L${ROOT}/usr/lib/"
export JPEG_CFLAGS="-I${ROOT}/usr/include/"
export JPEG_LIBS="-L${ROOT}/usr/lib/"
emerge "$@"


Now, emerging gimp pases the fontconfig problem, the pango and the babl problem, but fails at the bz2 check:

xmerge gimp:
checking whether i686-pc-linux-gnu-gcc understands -msse... yes
checking whether we can compile SSE code... yes
checking sys/ipc.h usability... yes
checking sys/ipc.h presence... yes
checking for sys/ipc.h... yes
checking sys/shm.h usability... yes
checking sys/shm.h presence... yes
checking for sys/shm.h... yes
checking whether shmctl IPC_RMID allowes subsequent attaches... assuming no
checking for shared memory transport type... sysv
checking whether symbols are prefixed... no
checking fd_set and sys/select... yes
checking for XmuClientWindow in -lXmu... no
checking for XShapeGetRectangles in -lXext... no
checking for XFIXES... yes
checking for gzsetparams in -lz... no
checking for BZ2_bzCompress in -lbz2... no
configure: error:
*** Checks for bzip2 library failed. You can build without it by passing
*** --without-bzip2 to configure but you won't be able to use compressed files then.


Is it possible to force emerge to look up for the libs and the includes only to my target system? Setting all those enviromentment-variables is quite annoying.
Back to top
View user's profile Send private message
musv
Advocate
Advocate


Joined: 01 Dec 2002
Posts: 3333
Location: de

PostPosted: Sun Nov 04, 2012 12:16 am    Post subject: Reply with quote

Ok, I tried something else:

As proposed I set the SYSROOT to my /usr/i686-pc-linux-gnu and merged the make.conf from the target machine with the cross-compiling make.conf in /usr/i686-pc-linux-gnu/etc/portage.

To get access to the headers and the libs of the target-machine I mounted the relevant directories into /usr/i686-pc-linux-gnu
Code:
mount -o bind /mnt/miniding/usr/include /usr/i686-pc-linux-gnu/usr/include
mount -o bind /mnt/miniding/usr/lib /usr/i686-pc-linux-gnu/usr/lib


The result is the same:
emerge gimp:
...
checking sys/shm.h presence... yes
checking for sys/shm.h... yes
checking whether shmctl IPC_RMID allowes subsequent attaches... assuming no
checking for shared memory transport type... sysv
checking whether symbols are prefixed... no
checking fd_set and sys/select... yes
checking for XmuClientWindow in -lXmu... no
checking for XShapeGetRectangles in -lXext... yes
checking for X11/extensions/shape.h... yes
checking for XFIXES... yes
checking for gzsetparams in -lz... no
checking for BZ2_bzCompress in -lbz2... no
configure: error:
*** Checks for bzip2 library failed. You can build without it by passing
*** --without-bzip2 to configure but you won't be able to use compressed files then.

!!! Please attach the following file when seeking support:
!!! /var/tmp/portage/media-gfx/gimp-2.8.2/work/gimp-2.8.2/config.log
 * ERROR: media-gfx/gimp-2.8.2 failed (configure phase):


Did anybody here really use a cross-compile environment? How did you solve the problem of the not found header files and libs?
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Sun Nov 04, 2012 1:02 am    Post subject: Reply with quote

musv,

I use a cross toolchain on a AMD64 to build for an ARM target (a Raspberry Pi) with mixed success.
A few things won't build because they attempt to run cross compiled code on the host as part of the build process.
Other things fail because of .la files. The linker gets pointed to the files on the host, instead of those in the target environment.

The easiest and most reliable way to build is to use distcc on the target in pump mode with helpers running a cross compiler.
It mostly just works. There are a few things that fail and get built locally.


If cross buildings was a 100% successful, you could install your cross toolchain and do for example
Code:
armv6j-hardfloat-linux-gnueabi-emerge @system
into an empty cross environment and it would just work.
It doesn't as perl and python won't build that way.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
musv
Advocate
Advocate


Joined: 01 Dec 2002
Posts: 3333
Location: de

PostPosted: Mon Nov 05, 2012 3:40 pm    Post subject: Reply with quote

NeddySeagoon wrote:
I use a cross toolchain on a AMD64 to build for an ARM target (a Raspberry Pi) with mixed success.
A few things won't build because they attempt to run cross compiled code on the host as part of the build process.
Other things fail because of .la files. The linker gets pointed to the files on the host, instead of those in the target environment.

That's what I'm afraid of.

I ran it before in a chroot. But after the change of the host CPU, some packages fail to build due to the movbe command of the target CPU (Atom), which the host CPU (Xeon) doesn't understand.

I made another quite crazy approach:
The installed packages on host and target are almost the same version. Means the 2 systems are almost identically which the installed packages concerns.

So I made a chroot:
Code:
mount -o bind /proc /mnt/miniding/proc
mount -o bind /dev /mnt/miniding/dev
mount -o bind /dev/pts /mnt/miniding/dev/pts
mount -o bind /usr/portage /mnt/miniding/usr/portage
mount -o bind /var/portage/distfiles /mnt/miniding/var/portage/distfiles
mount -t tmpfs tmpfs /mnt/miniding/var/tmp/portage
mount -o bind /bin /mnt/miniding/bin
mount -o bind /usr/bin /mnt/minding/usr/bin
chroot /mnt/miniding /bin/bash

The idea is:
  • Use the include, lib and pkgconfig stuff from the target without any problems of the paths.
  • Use /bin and /usr/bin from the host, so it should be able to execute it with the host cpu instructions.

Unfortunately this approach fails just right away. Even /bin/bash can't be executed. :(

NeddySeagoon wrote:
The easiest and most reliable way to build is to use distcc on the target in pump mode with helpers running a cross compiler.
It mostly just works. There are a few things that fail and get built locally.

But what do you do, if your resources (memory, disc) are not sufficient on the target machine? Or even worse, packages like webkit-gtk, which have to be compiled with MAKEOPTS="-j1". They will take a few hours on the target machine.

Until now I've used distcc only in non-pump mode. When I tried the pump mode some months ago, I didn't get it running. But anyway, distcc isn't comparable with building e.g. in a chroot environment completely on the host machine.

NeddySeagoon wrote:
If cross buildings was a 100% successful, you could install your cross toolchain and do for example
Code:
armv6j-hardfloat-linux-gnueabi-emerge @system
into an empty cross environment and it would just work.
It doesn't as perl and python won't build that way.

The cross environment works (gcc/g++, binutils). I was able to build simple packages. The problem are the big packages, which are worth to build on a bigger machine. For the small stuff I don't need the cross environment.

Thanks so far for your information. I guess I'll have to search more, to get that problems solved.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Mon Nov 05, 2012 7:28 pm    Post subject: Reply with quote

musv,

For lack of RAM, there is very little to do. My Pi has a whole 256Mb. I've not tried to build things like firefox or libre office yet :)
I use either an USB HDD for build space, or nfs. Either way its external. This ea

You could write an exception handler for the kernel to deal with the movbe instruction.
Every time the host CPU hits this, it raises an illegal instruction exception, which you may catch, run some software to emulate the movbe instruction than pass control back.
The program execution the movbe will not be able to tell the difference. The drawback is the time taken to do two context switches to execute what should be a single instruction.

Your "quite crazy approach" fails because inside the chroot, the kernel appears to be a 32 bit kernel, so refuses to run 64 bit code.
Look at uname -a both inside and outside the chroot. Thats what the linux32 prefix does in the linux32 chroot .... command.

My Atom based Acer One 110 builds everything for itself but both firefox and libre office want a day each, so I'm looking at a cross environment for it on my AMD64.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
musv
Advocate
Advocate


Joined: 01 Dec 2002
Posts: 3333
Location: de

PostPosted: Tue Nov 06, 2012 4:15 pm    Post subject: Reply with quote

For implementing the movbe instruction into my xeon kernel I don't have any knowledge. But I found a new idea:

Would a qemu-chroot be a usable solution?

Links:
Gentoo ARM
Gentoo Embedded handbook

How do I have to imagine this? Is there a performance loss through qemu?

The idea:
  1. emerge qemu-user
  2. mount binfmt_misc for atom (necessary?)
  3. chroot with mounting the atom machine via nfs into the qemu environment and etc, proc, portage from the host into qemu
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Tue Nov 06, 2012 8:00 pm    Post subject: Reply with quote

musv,

A qemu emulated system will be very slow as the CPU is emulated in software. All of it, not just the movbe.
You may be faster building on the Atom system.

The only qemu I have tested is SPARC on AMD64, which wants a whole 3.2GHz core to emulate a SPARC CPU running at 200 MHz.
It was a bit pointless as I have a real 440MHz SPARC.

Does qemu offer an atom target, including the movbe instruction?

The gcc compiler has a -mmovbe option, so you can tell gcc not to use movbe -mno-movbe in CFALGS should turn it off.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
musv
Advocate
Advocate


Joined: 01 Dec 2002
Posts: 3333
Location: de

PostPosted: Tue Nov 06, 2012 9:46 pm    Post subject: Reply with quote

Ok, I gave qemu-user a little chance, but I guess I did not fully understand how to install for a nfs-mounted existing environment. If I do according to the embedded handbook:
Code:
ROOT=/usr/i686-pc-linux-gnu/ emerge -K qemu-user

emerge begins to install more than 400 packages. So I just copied qemu-static-i386 and qemu-static-i386-binmft to /mnt/miniding/bin and did a chroot. I can call:
Code:
qemu-static-i386 -cpu n270

but nothing happens. So I gave up.

But your hint with disabling the movbe instruction gave me the point to solve this problem:
/etc/portage/env/nomovbe:
CFLAGS="-march=atom -O2 -fomit-frame-pointer -pipe -mno-movbe"
CXXFLAGS="${CFLAGS}"

The problematic packages are the tools to install the compiled stuff via chroot:
Code:
/usr/bin/gdk-pixbuf-csource -> x11-libs/gdk-pixbuf
/usr/bin/gtk-update-icon-cache -> x11-libs/gtk+
/usr/bin/update-mime-database -> x11-misc/shared-mime-info

So I switched off the movbe instruction for these packages.

ls -al /etc/portage/env/x11-*:
x11-libs:
insgesamt 8
drwxr-xr-x 1 root root 28  6. Nov 21:52 .
drwxr-xr-x 1 root root 94  6. Nov 22:38 ..
lrwxrwxrwx 1 root root 10  6. Nov 21:47 gdk-pixbuf -> ../nomovbe
lrwxrwxrwx 1 root root 10  6. Nov 21:52 gtk+ -> ../nomovbe

x11-misc:
insgesamt 4
drwxr-xr-x 1 root root 32  6. Nov 22:39 .
drwxr-xr-x 1 root root 94  6. Nov 22:38 ..
lrwxrwxrwx 1 root root 10  6. Nov 22:39 shared-mime-info -> ../nomovbe


After recompiling these packages the errors disappeared. And gimp compiled without problems. The KDE stuff has also some tools, which use movbe in the install process. But this I will figure out in the next big update.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Installing Gentoo All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum