qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how to build qemu-xxx-static


From: Frans de Boer
Subject: Re: how to build qemu-xxx-static
Date: Sat, 28 Aug 2021 13:37:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.0.1

On 8/28/21 12:47, Peter Maydell wrote:
On Fri, 27 Aug 2021 at 19:49, Frans de Boer <frans@fransdb.nl> wrote:
Following your pointers, I noticed that it was all about missing static 
libraries/header files. The error messages where not helpful at all. config.log 
provided some pointers.
Yeah. We tend to assume "the compiler works" a bit more than
perhaps we should.

Now I can configure, compile and start some activity like starting a shell 
script, which runs tar and continue with a child bash script to start 
configure, only to end with:

/sources-base/gcc-11.2.0/libstdc++-v3/configure 'CXXFLAGS=-g -O2 -D_GNU_SOURCE' 
--prefix=/usr --host=aarch64-cross-linux --disable-multilib --disable-nls 
--disable-libstdcxx-pch
/sources-base/gcc-11.2.0/libstdc++-v3/configure: This script requires a shell 
more modern than all
/sources-base/gcc-11.2.0/libstdc++-v3/configure: the shells that I found on 
your system.
/sources-base/gcc-11.2.0/libstdc++-v3/configure: Please tell 
bug-autoconf@gnu.org about your system,
/sources-base/gcc-11.2.0/libstdc++-v3/configure: including any error possibly 
output before this
/sources-base/gcc-11.2.0/libstdc++-v3/configure: message. Then install a modern 
shell, or manually run
/sources-base/gcc-11.2.0/libstdc++-v3/configure: the script under such a shell 
if you do have one.
------------------------------------------------------
However, it is the newest bash script, but configure can't find it, so it seems 
(see attached file).

Just extra info: all files have been checked to be compatible with ARM aarch64.
The shell script seems to be unable to find /bin/sh etc binaries.
In general configure and other shell scripts work in QEMU, so my
first guess is that the environment you're running QEMU in (which
you don't describe -- chroot? something else?) is not set up right.

Also, I am not sure, but when linking the static binary 'aarch64-linux-binfmt', 
I get a whole slew of message like below:

/usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/ld: 
/home/abuild/rpmbuild/BUILD/glib-2.68.4/x86_64-suse-linux/../glib/gutils.c:639: 
warning: Using 'getpwnam_r' in statically linked applications requires at 
runtime the shared libraries from the glibc version used for linking
/usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/ld: 
/home/abuild/rpmbuild/BUILD/glib-2.68.4/x86_64-suse-linux/../glib/gutils.c:645: 
warning: Using 'getpwuid_r' in statically linked applications requires at 
runtime the shared libraries from the glibc version used for linking
These are expected. They're because QEMU is linked against the host
glib library, and some parts of libglib use these libc functions like
getpwnam_r that won't work in a statically linked setup. But we know
that QEMU doesn't actually use the glib functions that use those
libc functions, so it's not a problem. Unfortunately there's no way
to suppress these messages (it would require changes in how libglib
splits their source code between .c files.)

I donĀ“t understand where the '/home/abuild/rpmbuild/BUILD/...' came from.
That's the path where whoever built the glib rpm for SUSE happened
to have their source code.

-- PMM
I use it with a chroot jail. The PATH variable is set and other programs can be found - including bash. Only within configure the shell can't be found, while the link /bin -> /usr/bin, so that should also be no problem, right? Not so, also when I replace the link with a real directory and a real version of bash, it does not work. So, either the configure script has an issue with running under chroot and using qemu-aarch64-binfmt for translations, or something else is going on. Is there a way similar to -strace for the static version 'qemu-aarch64-binfmt', just to see if that is the place where it goes wrong somehow?

Also, I tried to compile some other programs, but all of these stumble over the same configure issue. They can't find a proper version of the shell, which - for now - exist both under /usr/bin as well as /bin (no links).

Anyhow, it's not easy to cross build a new system using a different code base.

Regards, Frans.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]