[Qemu-devel] [RFC PATCH] Allow building without graphics support

[Qemu-devel] [RFC PATCH] Allow building without graphics support

[Scott Wood]

QEMU is sometimes used in embedded contexts, where graphical support
is unnecessary.  The ability to turn off graphics support not only
saves some space, but it eliminates the dependency on pixman.

Signed-off-by: Scott Wood <scottwood@freescale.com>
---
There are undoubtedly some rough edges that need to be cleaned up and
other parts of graphics code that could be compiled out -- this is mainly
meant to see what people think of the concept.

My immediate motivation was that the QEMU-supplied pixman was being a
pain to cross compile (especially without hacking up the generated QEMU
makefiles to pass additional things to pixman's configure), and in
general it would be nice to not have to carry around graphical baggage
when running on hardware that doesn't even have a display (so I was more
inclined to do this than to spend effort fixing the pixman build).
---
 Makefile.objs    |    7 +++++--
 configure        |   26 +++++++++++++++++++++++++-
 console.h        |    4 ++++
 hw/Makefile.objs |    4 ++++
 no-console.c     |    8 ++++++++
 qemu-char.c      |    2 ++
 qemu-pixman.c    |    1 +
 qemu-pixman.h    |    4 ++++
 ui/Makefile.objs |    2 ++
 ui/vnc.h         |    4 ++++
 vl.c             |   14 ++++++++++++--
 11 files changed, 71 insertions(+), 5 deletions(-)
 create mode 100644 no-console.c

diff --git a/Makefile.objs b/Makefile.objs
index 3c7abca..360500d 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -68,8 +68,11 @@ endif
 common-obj-y = $(block-obj-y) blockdev.o blockdev-nbd.o block/
 common-obj-y += net.o net/
 common-obj-y += qom/
-common-obj-y += readline.o console.o cursor.o
-common-obj-y += qemu-pixman.o
+common-obj-y += readline.o
+common-obj-$(CONFIG_GRAPHICS) += console.o cursor.o qemu-pixman.o
+ifneq ($(CONFIG_GRAPHICS),y)
+common-obj-y += no-console.o
+endif
 common-obj-y += $(oslib-obj-y)
 common-obj-$(CONFIG_WIN32) += os-win32.o
 common-obj-$(CONFIG_POSIX) += os-posix.o
diff --git a/configure b/configure
index 38b1cc6..6cb73e6 100755
--- a/configure
+++ b/configure
@@ -223,6 +223,7 @@ libiscsi=""
 coroutine=""
 seccomp=""
 glusterfs=""
+graphics="yes"
 
 # parse CC options first
 for opt do
@@ -880,6 +881,14 @@ for opt do
   ;;
   --enable-glusterfs) glusterfs="yes"
   ;;
+  --disable-graphics)
+    graphics="no"
+    vnc="no"
+    spice="no"
+    curses="no"
+  ;;
+  --enable-graphics) graphics="yes"
+  ;;
   *) echo "ERROR: unknown option $opt"; show_help="yes"
   ;;
   esac
@@ -1128,6 +1137,8 @@ echo "  --with-coroutine=BACKEND coroutine backend. Supported options:"
 echo "                           gthread, ucontext, sigaltstack, windows"
 echo "  --enable-glusterfs       enable GlusterFS backend"
 echo "  --disable-glusterfs      disable GlusterFS backend"
+echo "  --enable-graphics        enable graphics support (default)"
+echo "  --disable-graphics       disable graphics support"
 echo ""
 echo "NOTE: The object files are built at the place where configure is launched"
 exit 1
@@ -2126,6 +2137,14 @@ fi
 ##########################################
 # pixman support probe
 
+if test "$graphics" = "no"; then
+  pixman="not needed"
+  if test "$vnc" = "yes" -o "$spice" = "yes"; then
+    echo "ERROR: graphics disabled but vnc or spice enabled"
+    exit 1
+  fi
+fi
+
 if test "$pixman" = ""; then
   if $pkg_config --atleast-version=0.18.4 pixman-1 > /dev/null 2>&1; then
     pixman="system"
@@ -2136,7 +2155,7 @@ fi
 if test "$pixman" = "system"; then
   pixman_cflags=`$pkg_config --cflags pixman-1 2>/dev/null`
   pixman_libs=`$pkg_config --libs pixman-1 2>/dev/null`
-else
+elif test "$pixman" != "not needed"; then
   if test ! -d ${source_path}/pixman/pixman; then
     echo "ERROR: pixman not present (or older than 0.18.4). Your options:"
     echo "  (1) Preferred: Install the pixman devel package (any recent"
@@ -3257,6 +3276,7 @@ echo "build guest agent $guest_agent"
 echo "seccomp support   $seccomp"
 echo "coroutine backend $coroutine_backend"
 echo "GlusterFS support $glusterfs"
+echo "graphics          $graphics"
 
 if test "$sdl_too_old" = "yes"; then
 echo "-> Your SDL version is too old - please upgrade to have SDL support"
@@ -3603,6 +3623,10 @@ if test "$glusterfs" = "yes" ; then
   echo "CONFIG_GLUSTERFS=y" >> $config_host_mak
 fi
 
+if test "$graphics" = "yes" ; then
+  echo "CONFIG_GRAPHICS=y" >> $config_host_mak
+fi
+
 # USB host support
 case "$usb" in
 linux)
diff --git a/console.h b/console.h
index 50a0512..49d8469 100644
--- a/console.h
+++ b/console.h
@@ -120,8 +120,10 @@ struct PixelFormat {
 };
 
 struct DisplaySurface {
+#ifdef CONFIG_GRAPHICS
     pixman_format_code_t format;
     pixman_image_t *image;
+#endif
     uint8_t flags;
 
     struct PixelFormat pf;
@@ -340,6 +342,7 @@ static inline bool dpy_cursor_define_supported(struct DisplayState *s)
     return false;
 }
 
+#ifdef CONFIG_GRAPHICS
 static inline int ds_get_linesize(DisplayState *ds)
 {
     return pixman_image_get_stride(ds->surface->image);
@@ -401,6 +404,7 @@ static inline int ds_get_bmask(DisplayState *ds)
 {
     return ds->surface->pf.bmask;
 }
+#endif
 
 #ifdef CONFIG_CURSES
 #include <curses.h>
diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index d581d8d..6297759 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -127,12 +127,14 @@ common-obj-y += sysbus.o isa-bus.o
 common-obj-y += qdev-addr.o
 
 # VGA
+ifeq ($(CONFIG_GRAPHICS), y)
 common-obj-$(CONFIG_VGA_PCI) += vga-pci.o
 common-obj-$(CONFIG_VGA_ISA) += vga-isa.o
 common-obj-$(CONFIG_VGA_ISA_MM) += vga-isa-mm.o
 common-obj-$(CONFIG_VMWARE_VGA) += vmware_vga.o
 common-obj-$(CONFIG_VMMOUSE) += vmmouse.o
 common-obj-$(CONFIG_VGA_CIRRUS) += cirrus_vga.o
+endif
 
 common-obj-$(CONFIG_RC4030) += rc4030.o
 common-obj-$(CONFIG_DP8393X) += dp8393x.o
@@ -200,7 +202,9 @@ obj-$(CONFIG_SOFTMMU) += vhost_net.o
 obj-$(CONFIG_VHOST_NET) += vhost.o
 obj-$(CONFIG_REALLY_VIRTFS) += 9pfs/
 obj-$(CONFIG_NO_PCI) += pci-stub.o
+ifeq ($(CONFIG_GRAPHICS), y)
 obj-$(CONFIG_VGA) += vga.o
+endif
 obj-$(CONFIG_SOFTMMU) += device-hotplug.o
 obj-$(CONFIG_XEN) += xen_domainbuild.o xen_machine_pv.o
 
diff --git a/no-console.c b/no-console.c
new file mode 100644
index 0000000..f4e418f
--- /dev/null
+++ b/no-console.c
@@ -0,0 +1,8 @@
+#include "qemu-common.h"
+#include "error.h"
+#include "qmp-commands.h"
+
+void qmp_screendump(const char *filename, Error **errp)
+{
+  error_setg(errp, "device doesn't support screendump\n");
+}
diff --git a/qemu-char.c b/qemu-char.c
index 242b799..e488e2c 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -2735,7 +2735,9 @@ static const struct {
     { .name = "socket",    .open = qemu_chr_open_socket },
     { .name = "udp",       .open = qemu_chr_open_udp },
     { .name = "msmouse",   .open = qemu_chr_open_msmouse },
+#ifdef CONFIG_GRAPHICS
     { .name = "vc",        .open = text_console_init },
+#endif
 #ifdef _WIN32
     { .name = "file",      .open = qemu_chr_open_win_file_out },
     { .name = "pipe",      .open = qemu_chr_open_win_pipe },
diff --git a/qemu-pixman.c b/qemu-pixman.c
index e46e180..821a525 100644
--- a/qemu-pixman.c
+++ b/qemu-pixman.c
@@ -3,6 +3,7 @@
  * See the COPYING file in the top-level directory.
  */
 
+#include "qemu-common.h"
 #include "qemu-pixman.h"
 
 int qemu_pixman_get_type(int rshift, int gshift, int bshift)
diff --git a/qemu-pixman.h b/qemu-pixman.h
index bee55eb..0844816 100644
--- a/qemu-pixman.h
+++ b/qemu-pixman.h
@@ -6,6 +6,8 @@
 #ifndef QEMU_PIXMAN_H
 #define QEMU_PIXMAN_H
 
+#ifdef CONFIG_GRAPHICS
+
 #include <pixman.h>
 
 #include "console.h"
@@ -36,4 +38,6 @@ pixman_image_t *qemu_pixman_mirror_create(pixman_format_code_t format,
                                           pixman_image_t *image);
 void qemu_pixman_image_unref(pixman_image_t *image);
 
+#endif /* CONFIG_GRAPHICS */
+
 #endif /* QEMU_PIXMAN_H */
diff --git a/ui/Makefile.objs b/ui/Makefile.objs
index adc07be..91cca0b 100644
--- a/ui/Makefile.objs
+++ b/ui/Makefile.objs
@@ -8,7 +8,9 @@ vnc-obj-y += vnc-jobs.o
 
 common-obj-y += keymaps.o
 common-obj-$(CONFIG_SPICE) += spice-core.o spice-input.o spice-display.o
+ifeq ($(CONFIG_GRAPHICS),y)
 common-obj-$(CONFIG_SDL) += sdl.o sdl_zoom.o x_keymap.o
+endif
 common-obj-$(CONFIG_COCOA) += cocoa.o
 common-obj-$(CONFIG_CURSES) += curses.o
 common-obj-$(CONFIG_VNC) += $(vnc-obj-y)
diff --git a/ui/vnc.h b/ui/vnc.h
index 6141e88..60b19cd 100644
--- a/ui/vnc.h
+++ b/ui/vnc.h
@@ -41,6 +41,8 @@
 #include "vnc-palette.h"
 #include "vnc-enc-zrle.h"
 
+#ifdef CONFIG_VNC
+
 // #define _VNC_DEBUG 1
 
 #ifdef _VNC_DEBUG
@@ -560,4 +562,6 @@ int vnc_zrle_send_framebuffer_update(VncState *vs, int x, int y, int w, int h);
 int vnc_zywrle_send_framebuffer_update(VncState *vs, int x, int y, int w, int h);
 void vnc_zrle_clear(VncState *vs);
 
+#endif
+
 #endif /* __QEMU_VNC_H */
diff --git a/vl.c b/vl.c
index a3ab384..5679db3 100644
--- a/vl.c
+++ b/vl.c
@@ -180,8 +180,14 @@ int main(int argc, char **argv)
 static const char *data_dir;
 const char *bios_name = NULL;
 enum vga_retrace_method vga_retrace_method = VGA_RETRACE_DUMB;
+
+#ifdef CONFIG_GRAPHICS
 DisplayType display_type = DT_DEFAULT;
 static int display_remote;
+#else
+DisplayType display_type = DT_NOGRAPHIC;
+#endif
+
 const char* keyboard_layout = NULL;
 ram_addr_t ram_size;
 const char *mem_path = NULL;
@@ -2532,7 +2538,9 @@ int main(int argc, char **argv, char **envp)
     const char *initrd_filename;
     const char *kernel_filename, *kernel_cmdline;
     char boot_devices[33] = "cad"; /* default to HD->floppy->CD-ROM */
+#ifdef CONFIG_GRAPHICS
     DisplayState *ds;
+#endif
     int cyls, heads, secs, translation;
     QemuOpts *hda_opts = NULL, *opts, *machine_opts;
     QemuOptsList *olist;
@@ -3887,6 +3895,7 @@ int main(int argc, char **argv, char **envp)
 
     net_check_clients();
 
+#ifdef CONFIG_GRAPHICS
     /* just use the first displaystate for the moment */
     ds = get_displaystate();
 
@@ -3927,7 +3936,7 @@ int main(int argc, char **argv, char **envp)
     default:
         break;
     }
-
+#endif /* CONFIG_GRAPHICS */
     /* must be after terminal init, SDL library changes signal handlers */
     os_setup_signal_handling();
 
@@ -3954,9 +3963,10 @@ int main(int argc, char **argv, char **envp)
         qemu_spice_display_init(ds);
     }
 #endif
-
+#ifdef CONFIG_GRAPHICS
     /* display setup */
     text_consoles_set_display(ds);
+#endif
 
     if (foreach_device_config(DEV_GDB, gdbserver_start) < 0) {
         exit(1);
-- 
1.7.9.5

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Stefan Weil]

Am 12.12.2012 04:18, schrieb Scott Wood:
> QEMU is sometimes used in embedded contexts, where graphical support
> is unnecessary.  The ability to turn off graphics support not only
> saves some space, but it eliminates the dependency on pixman.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> There are undoubtedly some rough edges that need to be cleaned up and
> other parts of graphics code that could be compiled out -- this is mainly
> meant to see what people think of the concept.
>
> My immediate motivation was that the QEMU-supplied pixman was being a
> pain to cross compile (especially without hacking up the generated QEMU
> makefiles to pass additional things to pixman's configure), and in
> general it would be nice to not have to carry around graphical baggage
> when running on hardware that doesn't even have a display (so I was more
> inclined to do this than to spend effort fixing the pixman build).

Hi,

cross compilation works for me with the internal pixman.
Here is an example which I use to compile Windows 64 bit
executables on Debian:

./configure' '--cross-prefix=amd64-mingw32msvc-'

Are there still problems with cross compilation in latest QEMU?

Regards,
Stefan Weil

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Gerd Hoffmann]

On 12/12/12 04:18, Scott Wood wrote:
> QEMU is sometimes used in embedded contexts, where graphical support
> is unnecessary.  The ability to turn off graphics support not only
> saves some space, but it eliminates the dependency on pixman.

We have tons of hand-crafted pixel shuffeling code all over the place
which I want replace with pixman library calls.  It's a long road and
will take quite some time.

I wanna have pixman as core service in qemu for that, not some optional
add-on.

> My immediate motivation was that the QEMU-supplied pixman was being a
> pain to cross compile (especially without hacking up the generated QEMU
> makefiles to pass additional things to pixman's configure),

We pass on cross-prefix to pixman's configure, so it should
JustWork[tm].  And it actually works for windows cross builds using the
mingw toolchain.  If it doesn't work for your setup I'd much prefer to
fix that.

> and in
> general it would be nice to not have to carry around graphical baggage
> when running on hardware that doesn't even have a display (so I was more
> inclined to do this than to spend effort fixing the pixman build).

I run qemu on headless machines alot, then connect via vnc/spice ...

cheers,
  Gerd

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[John Spencer]

On 12/12/2012 04:18 AM, Scott Wood wrote:
> QEMU is sometimes used in embedded contexts, where graphical support
> is unnecessary.  The ability to turn off graphics support not only
> saves some space, but it eliminates the dependency on pixman.
>
> Signed-off-by: Scott Wood<scottwood@freescale.com>
> ---
> There are undoubtedly some rough edges that need to be cleaned up and
> other parts of graphics code that could be compiled out -- this is mainly
> meant to see what people think of the concept.
>
> My immediate motivation was that the QEMU-supplied pixman was being a
> pain to cross compile (especially without hacking up the generated QEMU
> makefiles to pass additional things to pixman's configure), and in
> general it would be nice to not have to carry around graphical baggage
> when running on hardware that doesn't even have a display (so I was more
> inclined to do this than to spend effort fixing the pixman build).
> ---

very nice, i hope this one makes it upstream.
it's always good to minimize external dependencies, or make them 
optional when they're unneeded in some cases.
i can imagine that qemu terminal mode is often sufficient, for example
when using rob landley's pre-built aboriginal linux system images.

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Peter Maydell]

On 12 December 2012 03:18, Scott Wood <scottwood@freescale.com> wrote:
> QEMU is sometimes used in embedded contexts, where graphical support
> is unnecessary.  The ability to turn off graphics support not only
> saves some space, but it eliminates the dependency on pixman.

I would expect that we'd want to use pixman in the emulation
of graphics devices (which should be visible to the guest even
if the host doesn't have display support).

> My immediate motivation was that the QEMU-supplied pixman was being a
> pain to cross compile

Problems with cross compilation should be reported as bugs
so we can fix them -- we need to fix them anyway for the more
common case where there is host graphics support.

-- PMM

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Andreas Färber]

Am 12.12.2012 17:28, schrieb John Spencer:
> On 12/12/2012 04:18 AM, Scott Wood wrote:
>> QEMU is sometimes used in embedded contexts, where graphical support
>> is unnecessary.  The ability to turn off graphics support not only
>> saves some space, but it eliminates the dependency on pixman.
>>
>> Signed-off-by: Scott Wood<scottwood@freescale.com>
>> ---
>> There are undoubtedly some rough edges that need to be cleaned up and
>> other parts of graphics code that could be compiled out -- this is mainly
>> meant to see what people think of the concept.
>>
>> My immediate motivation was that the QEMU-supplied pixman was being a
>> pain to cross compile (especially without hacking up the generated QEMU
>> makefiles to pass additional things to pixman's configure), and in
>> general it would be nice to not have to carry around graphical baggage
>> when running on hardware that doesn't even have a display (so I was more
>> inclined to do this than to spend effort fixing the pixman build).
>> ---
> 
> very nice, i hope this one makes it upstream.
> it's always good to minimize external dependencies, or make them
> optional when they're unneeded in some cases.

There is already a patch by Robert Schiele on the list, let's not
reinvent the wheel here. That part should be pretty uncontroversial.
What this patch does on top is prone to clash with a number of ongoing
refactorings so I'd rather hold that off a bit.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Andreas Färber]

Am 12.12.2012 17:47, schrieb Peter Maydell:
> On 12 December 2012 03:18, Scott Wood <scottwood@freescale.com> wrote:
>> QEMU is sometimes used in embedded contexts, where graphical support
>> is unnecessary.  The ability to turn off graphics support not only
>> saves some space, but it eliminates the dependency on pixman.
> 
> I would expect that we'd want to use pixman in the emulation
> of graphics devices (which should be visible to the guest even
> if the host doesn't have display support).
> 
>> My immediate motivation was that the QEMU-supplied pixman was being a
>> pain to cross compile
> 
> Problems with cross compilation should be reported as bugs
> so we can fix them -- we need to fix them anyway for the more
> common case where there is host graphics support.

I already reported that the submodule does not configure on OSX/ppc
v10.5.8 - apparently due to some PKG_ macros not getting resolved. I
suspected aclocal not picking up pkg.m4 file but setting ACLOCAL_FLAGS
did not help. Do we need a more modern pkg-config version than we are
testing for?
Another issue seemed to be that our Makefile did not take into account
that I may be building with, e.g., "gcc -arch ppc64" and passing a
specific $PATH for 64-bit libraries / aclocal / pkgconfig to our configure.

The latest stable pixman configured but didn't compile on OSX/ppc due to
undefined identifiers or something. (The broken submodule version makes
it unhandy to fix this.)
This is holding up my Cocoa review of the gfx_ hook (that you haven't
jumped in to help out for v1.3) and I seriously doubt that it makes any
difference if I go through the hoops of posting the same info on
Launchpad when it Simply Works(tm) on Linux distros...

Testing on OSX/i386 v10.6 is still on my TODO list.

Andreas

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Peter Maydell]

On 12 December 2012 17:09, Andreas Färber <andreas.faerber@web.de> wrote:
> I already reported that the submodule does not configure on OSX/ppc
> v10.5.8 - apparently due to some PKG_ macros not getting resolved. I
> suspected aclocal not picking up pkg.m4 file but setting ACLOCAL_FLAGS
> did not help. Do we need a more modern pkg-config version than we are
> testing for?
> Another issue seemed to be that our Makefile did not take into account
> that I may be building with, e.g., "gcc -arch ppc64" and passing a
> specific $PATH for 64-bit libraries / aclocal / pkgconfig to our configure.

Hmm. On my OSX 10.8.2 box we pick up and use a system pixman.
Forcing the internal pixman compiles, at least (haven't tested
running it since I'm remote from the box currently). But that's
just using the default C compiler and options.

> This is holding up my Cocoa review of the gfx_ hook (that you haven't
> jumped in to help out for v1.3)

Yeah, sorry. MacOSX stuff is something I do in my spare time
so it's the first to fall off the end of the queue, I'm afraid.

-- PMM

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Paolo Bonzini]

Il 12/12/2012 18:09, Andreas Färber ha scritto:
>> > Problems with cross compilation should be reported as bugs
>> > so we can fix them -- we need to fix them anyway for the more
>> > common case where there is host graphics support.
> I already reported that the submodule does not configure on OSX/ppc
> v10.5.8 - apparently due to some PKG_ macros not getting resolved

Have you tried simply installing pixman from fink or macports or
homebrew (or whatever is fancy these days...)?

Paolo

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Scott Wood]

On 12/12/2012 12:46:44 AM, Stefan Weil wrote:
> Am 12.12.2012 04:18, schrieb Scott Wood:
>> QEMU is sometimes used in embedded contexts, where graphical support
>> is unnecessary.  The ability to turn off graphics support not only
>> saves some space, but it eliminates the dependency on pixman.
>> 
>> Signed-off-by: Scott Wood <scottwood@freescale.com>
>> ---
>> There are undoubtedly some rough edges that need to be cleaned up and
>> other parts of graphics code that could be compiled out -- this is  
>> mainly
>> meant to see what people think of the concept.
>> 
>> My immediate motivation was that the QEMU-supplied pixman was being a
>> pain to cross compile (especially without hacking up the generated  
>> QEMU
>> makefiles to pass additional things to pixman's configure), and in
>> general it would be nice to not have to carry around graphical  
>> baggage
>> when running on hardware that doesn't even have a display (so I was  
>> more
>> inclined to do this than to spend effort fixing the pixman build).
> 
> Hi,
> 
> cross compilation works for me with the internal pixman.
> Here is an example which I use to compile Windows 64 bit
> executables on Debian:
> 
> ./configure' '--cross-prefix=amd64-mingw32msvc-'
> 
> Are there still problems with cross compilation in latest QEMU?

It doesn't seem to like my --cross-prefix being a full path rather than  
being a recognized target pattern:

checking host system type... Invalid configuration  
`/home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu':  
machine  
`/home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc'  
not recognized
configure: error: /bin/bash /home/scott/fsl/git/qemu/pixman/config.sub  
/home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu  
failed
make: *** [pixman/Makefile] Error 1

When I forced --host=powerpc-linux into the pixman configure command in  
QEMU's generated Makefile, it got past that, but it built everything  
with the native compiler:

checking build system type... x86_64-unknown-linux-gnu
checking host system type... powerpc-unknown-linux-gnu
checking for powerpc-linux-gcc... no
checking for gcc... gcc

Looking a bit more closely, it seems that it's the QEMU rather than  
pixman's autoconf that is making the bad assumption about the format of  
--cross-prefix (I really wasn't up for wading in autoconf).  Running  
basename on cross-prefix and explicitly supplying CC and such to pixman  
would help, though there still should be a way to pass in an explicit  
host tuple if you have an unusually-named toolchain.

-Scott

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Scott Wood]

On 12/12/2012 10:47:04 AM, Peter Maydell wrote:
> On 12 December 2012 03:18, Scott Wood <scottwood@freescale.com> wrote:
> > QEMU is sometimes used in embedded contexts, where graphical support
> > is unnecessary.  The ability to turn off graphics support not only
> > saves some space, but it eliminates the dependency on pixman.
> 
> I would expect that we'd want to use pixman in the emulation
> of graphics devices (which should be visible to the guest even
> if the host doesn't have display support).

And those devices would have a dependency on the QEMU graphics  
subsystem.  Not all targets have graphics devices to be emulated.

> > My immediate motivation was that the QEMU-supplied pixman was being  
> a
> > pain to cross compile
> 
> Problems with cross compilation should be reported as bugs
> so we can fix them -- we need to fix them anyway for the more
> common case where there is host graphics support.

Sure.  It wasn't meant as a long-term alternative to fixing pixman  
issues, so much as as a final nudge to do something I'd wanted to do  
before.

-Scott

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Scott Wood]

On 12/12/2012 10:54:04 AM, Andreas Färber wrote:
> Am 12.12.2012 17:28, schrieb John Spencer:
> > On 12/12/2012 04:18 AM, Scott Wood wrote:
> >> QEMU is sometimes used in embedded contexts, where graphical  
> support
> >> is unnecessary.  The ability to turn off graphics support not only
> >> saves some space, but it eliminates the dependency on pixman.
> >>
> >> Signed-off-by: Scott Wood<scottwood@freescale.com>
> >> ---
> >> There are undoubtedly some rough edges that need to be cleaned up  
> and
> >> other parts of graphics code that could be compiled out -- this is  
> mainly
> >> meant to see what people think of the concept.
> >>
> >> My immediate motivation was that the QEMU-supplied pixman was  
> being a
> >> pain to cross compile (especially without hacking up the generated  
> QEMU
> >> makefiles to pass additional things to pixman's configure), and in
> >> general it would be nice to not have to carry around graphical  
> baggage
> >> when running on hardware that doesn't even have a display (so I  
> was more
> >> inclined to do this than to spend effort fixing the pixman build).
> >> ---
> >
> > very nice, i hope this one makes it upstream.
> > it's always good to minimize external dependencies, or make them
> > optional when they're unneeded in some cases.
> 
> There is already a patch by Robert Schiele on the list, let's not
> reinvent the wheel here. That part should be pretty uncontroversial.
> What this patch does on top is prone to clash with a number of ongoing
> refactorings so I'd rather hold that off a bit.

Ah, didn't notice that -- though tying it to CONFIG_USER_ONLY doesn't  
help my use case.

-Scott

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Scott Wood]

On 12/12/2012 01:52:29 AM, Gerd Hoffmann wrote:
> On 12/12/12 04:18, Scott Wood wrote:
> > QEMU is sometimes used in embedded contexts, where graphical support
> > is unnecessary.  The ability to turn off graphics support not only
> > saves some space, but it eliminates the dependency on pixman.
> 
> We have tons of hand-crafted pixel shuffeling code all over the place
> which I want replace with pixman library calls.  It's a long road and
> will take quite some time.
> 
> I wanna have pixman as core service in qemu for that, not some  
> optional
> add-on.

Why?  Isn't modularity a good thing?  It can still be a core service  
for any part of QEMU that deals with graphics.

> > My immediate motivation was that the QEMU-supplied pixman was being  
> a
> > pain to cross compile (especially without hacking up the generated  
> QEMU
> > makefiles to pass additional things to pixman's configure),
> 
> We pass on cross-prefix to pixman's configure, so it should
> JustWork[tm].

That's actually what was breaking it (I gave more details in another  
e-mail in this thread).  cross-prefix and host tuple are not quite the  
same thing.

> > and in
> > general it would be nice to not have to carry around graphical  
> baggage
> > when running on hardware that doesn't even have a display (so I was  
> more
> > inclined to do this than to spend effort fixing the pixman build).
> 
> I run qemu on headless machines alot, then connect via vnc/spice ...

So then don't turn off graphics support in your build, just as you  
don't turn off vnc/spice. :-P

Another thing that is missing on the hardware I'm talking about is a  
hard drive, so overly large qemu binaries are also not fun.

-Scott

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Stefan Weil]

Am 13.12.2012 01:48, schrieb Scott Wood:
> On 12/12/2012 12:46:44 AM, Stefan Weil wrote:
>> Am 12.12.2012 04:18, schrieb Scott Wood:
>>> QEMU is sometimes used in embedded contexts, where graphical support
>>> is unnecessary.  The ability to turn off graphics support not only
>>> saves some space, but it eliminates the dependency on pixman.
>>>
>>> Signed-off-by: Scott Wood <scottwood@freescale.com>
>>> ---
>>> There are undoubtedly some rough edges that need to be cleaned up and
>>> other parts of graphics code that could be compiled out -- this is 
>>> mainly
>>> meant to see what people think of the concept.
>>>
>>> My immediate motivation was that the QEMU-supplied pixman was being a
>>> pain to cross compile (especially without hacking up the generated QEMU
>>> makefiles to pass additional things to pixman's configure), and in
>>> general it would be nice to not have to carry around graphical baggage
>>> when running on hardware that doesn't even have a display (so I was 
>>> more
>>> inclined to do this than to spend effort fixing the pixman build).
>>
>> Hi,
>>
>> cross compilation works for me with the internal pixman.
>> Here is an example which I use to compile Windows 64 bit
>> executables on Debian:
>>
>> ./configure' '--cross-prefix=amd64-mingw32msvc-'
>>
>> Are there still problems with cross compilation in latest QEMU?
>
> It doesn't seem to like my --cross-prefix being a full path rather 
> than being a recognized target pattern:
>
> checking host system type... Invalid configuration 
> `/home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu': 
> machine 
> `/home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc' 
> not recognized
> configure: error: /bin/bash /home/scott/fsl/git/qemu/pixman/config.sub 
> /home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu 
> failed
> make: *** [pixman/Makefile] Error 1
>
> When I forced --host=powerpc-linux into the pixman configure command 
> in QEMU's generated Makefile, it got past that, but it built 
> everything with the native compiler:
>
> checking build system type... x86_64-unknown-linux-gnu
> checking host system type... powerpc-unknown-linux-gnu
> checking for powerpc-linux-gcc... no
> checking for gcc... gcc
>
> Looking a bit more closely, it seems that it's the QEMU rather than 
> pixman's autoconf that is making the bad assumption about the format 
> of --cross-prefix (I really wasn't up for wading in autoconf).  
> Running basename on cross-prefix and explicitly supplying CC and such 
> to pixman would help, though there still should be a way to pass in an 
> explicit host tuple if you have an unusually-named toolchain.
>
> -Scott

Indeed, --cross-prefixdoes not support absolute path names.

I assume that the executables in
/home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/binare 
without prefix
(gcc, ld, ...). Then there must also be the same executables with prefix
(powerpc-linux-gnu-gcc, powerpc-linux-gnu-ld, ...). These must be 
somewhere in PATH.
Use --cross-prefix=powerpc-linux-gnu-(note the "-" at the end).
Then pixman would be configured with --host=powerpc-linux-gnu and should 
find
the compiler. It won't find the compiler powerpc-linux-gcc when its real 
name is
powerpc-linux-gnu-gcc.

-Stefan

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Gerd Hoffmann]

On 12/13/12 01:57, Scott Wood wrote:
> On 12/12/2012 01:52:29 AM, Gerd Hoffmann wrote:
>> On 12/12/12 04:18, Scott Wood wrote:
>> > QEMU is sometimes used in embedded contexts, where graphical support
>> > is unnecessary.  The ability to turn off graphics support not only
>> > saves some space, but it eliminates the dependency on pixman.
>>
>> We have tons of hand-crafted pixel shuffeling code all over the place
>> which I want replace with pixman library calls.  It's a long road and
>> will take quite some time.
>>
>> I wanna have pixman as core service in qemu for that, not some optional
>> add-on.
> 
> Why?  Isn't modularity a good thing?  It can still be a core service for
> any part of QEMU that deals with graphics.

A pretty central data structure in qemu (DisplayState / DisplaySurface)
carries a pixman image, not some module which can easily be made
optional.  Just look at the tons of #ifdef'ery you have to do to get
this going.

> Another thing that is missing on the hardware I'm talking about is a
> hard drive, so overly large qemu binaries are also not fun.

Oh, using pixman will actually make the qemu binaries smaller as we can
replace code with library calls.

Independant of that: allow easily stripping down qemu by removing stuff
you don't want would be a nice (but non-trivial) project.

cheers,
  Gerd

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Alexander Graf]

On 13.12.2012, at 08:16, Gerd Hoffmann wrote:

> On 12/13/12 01:57, Scott Wood wrote:
>> On 12/12/2012 01:52:29 AM, Gerd Hoffmann wrote:
>>> On 12/12/12 04:18, Scott Wood wrote:
>>>> QEMU is sometimes used in embedded contexts, where graphical support
>>>> is unnecessary.  The ability to turn off graphics support not only
>>>> saves some space, but it eliminates the dependency on pixman.
>>> 
>>> We have tons of hand-crafted pixel shuffeling code all over the place
>>> which I want replace with pixman library calls.  It's a long road and
>>> will take quite some time.
>>> 
>>> I wanna have pixman as core service in qemu for that, not some optional
>>> add-on.
>> 
>> Why?  Isn't modularity a good thing?  It can still be a core service for
>> any part of QEMU that deals with graphics.
> 
> A pretty central data structure in qemu (DisplayState / DisplaySurface)
> carries a pixman image, not some module which can easily be made
> optional.  Just look at the tons of #ifdef'ery you have to do to get
> this going.

His point is that anything related to DisplayState should be optional.

>> Another thing that is missing on the hardware I'm talking about is a
>> hard drive, so overly large qemu binaries are also not fun.
> 
> Oh, using pixman will actually make the qemu binaries smaller as we can
> replace code with library calls.

That doesn't help for the full system load. We're talking of flash chips in the MB range with an embedded initrd here, so you'd have to factor in pixman as well, as without QEMU there wouldn't be a pixman in the system in the first place.

The same argument really holds true for TCG modularization which nobody tackled yet though.

> Independant of that: allow easily stripping down qemu by removing stuff
> you don't want would be a nice (but non-trivial) project.

Yup :).

For the time being, almost none of my boxes can compile QEMU anymore. I have pixman versions

  0.12.0
  0.16.0
  0.16.4
  0.26.0

and I really don't want to mess with git submodules. Every time I checked out SLOF I ended up with bogus submodule commits in random patches. It's a real nightmare.


Alex

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Peter Maydell]

On 13 December 2012 14:44, Alexander Graf <agraf@suse.de> wrote:
> That doesn't help for the full system load. We're talking of flash
> chips in the MB range with an embedded initrd here

This is an edge case, and I think our approach here ought to
be to say "we welcome patches which provide a coherent
module system for QEMU"...

-- PMM

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Gerd Hoffmann]

  Hi,

>> A pretty central data structure in qemu (DisplayState /
>> DisplaySurface) carries a pixman image, not some module which can
>> easily be made optional.  Just look at the tons of #ifdef'ery you
>> have to do to get this going.
> 
> His point is that anything related to DisplayState should be
> optional.

We can try, but sprinkling #ifdefs all over the place isn't the way to
go.  Separate any Display* stuff, say to display.[ch].  Include
display.h only when needed.  Then not compiling the object files
will do the trick, and maybe one or two #ifdefs in vl.c.

At least in theory.  In practice it probably needs some more cleanups so
it actually works.

And the "not compiling" part brings us back to the "easy way to strip
down qemu" part.  I'd love to have something (kconfig?) which allows to
pick which device emulations, block formats, ... I wanna include into qemu.

>> Oh, using pixman will actually make the qemu binaries smaller as we
>> can replace code with library calls.

> That doesn't help for the full system load. We're talking of flash
> chips in the MB range with an embedded initrd here, so you'd have to
> factor in pixman as well, as without QEMU there wouldn't be a pixman
> in the system in the first place.

Most systems have pixman anyway, but yes I can see embedded being different.

> For the time being, almost none of my boxes can compile QEMU anymore.
> I have pixman versions
> 
> 0.12.0 0.16.0 0.16.4 0.26.0

Dunno about 0.12 (see other mail), but 0.16+ should be fine (once the
pending patch is updated and committed).

cheers,
  Gerd

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Alexander Graf]

On 13.12.2012, at 16:16, Gerd Hoffmann wrote:

>  Hi,
> 
>>> A pretty central data structure in qemu (DisplayState /
>>> DisplaySurface) carries a pixman image, not some module which can
>>> easily be made optional.  Just look at the tons of #ifdef'ery you
>>> have to do to get this going.
>> 
>> His point is that anything related to DisplayState should be
>> optional.
> 
> We can try, but sprinkling #ifdefs all over the place isn't the way to
> go.  Separate any Display* stuff, say to display.[ch].  Include
> display.h only when needed.  Then not compiling the object files
> will do the trick, and maybe one or two #ifdefs in vl.c.
> 
> At least in theory.  In practice it probably needs some more cleanups so
> it actually works.
> 
> And the "not compiling" part brings us back to the "easy way to strip
> down qemu" part.  I'd love to have something (kconfig?) which allows to
> pick which device emulations, block formats, ... I wanna include into qemu.

I 100% concur. I was merely trying to make sure we're all on the same page :).

> 
>>> Oh, using pixman will actually make the qemu binaries smaller as we
>>> can replace code with library calls.
> 
>> That doesn't help for the full system load. We're talking of flash
>> chips in the MB range with an embedded initrd here, so you'd have to
>> factor in pixman as well, as without QEMU there wouldn't be a pixman
>> in the system in the first place.
> 
> Most systems have pixman anyway, but yes I can see embedded being different.
> 
>> For the time being, almost none of my boxes can compile QEMU anymore.
>> I have pixman versions
>> 
>> 0.12.0 0.16.0 0.16.4 0.26.0
> 
> Dunno about 0.12 (see other mail), but 0.16+ should be fine (once the
> pending patch is updated and committed).

Yeah, though I'd really prefer if we do the configure check based on features, not based on versions. That way backports for example would work.


Alex

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Scott Wood]

On 12/13/2012 12:31:14 AM, Stefan Weil wrote:
> Am 13.12.2012 01:48, schrieb Scott Wood:
>> It doesn't seem to like my --cross-prefix being a full path rather  
>> than being a recognized target pattern:
>> 
>> checking host system type... Invalid configuration  
>> `/home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu':  
>> machine  
>> `/home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc'  
>> not recognized
>> configure: error: /bin/bash  
>> /home/scott/fsl/git/qemu/pixman/config.sub  
>> /home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu  
>> failed
>> make: *** [pixman/Makefile] Error 1
>> 
>> When I forced --host=powerpc-linux into the pixman configure command  
>> in QEMU's generated Makefile, it got past that, but it built  
>> everything with the native compiler:
>> 
>> checking build system type... x86_64-unknown-linux-gnu
>> checking host system type... powerpc-unknown-linux-gnu
>> checking for powerpc-linux-gcc... no
>> checking for gcc... gcc
>> 
>> Looking a bit more closely, it seems that it's the QEMU rather than  
>> pixman's autoconf that is making the bad assumption about the format  
>> of --cross-prefix (I really wasn't up for wading in autoconf).   
>> Running basename on cross-prefix and explicitly supplying CC and  
>> such to pixman would help, though there still should be a way to  
>> pass in an explicit host tuple if you have an unusually-named  
>> toolchain.
>> 
>> -Scott
> 
> Indeed, --cross-prefixdoes not support absolute path names.
> 
> I assume that the executables in
> /home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/binare  
> without prefix
> (gcc, ld, ...).

No, they are with prefix, just not in $PATH.  I have more than one  
"powerpc-linux-gnu" toolchain and I don't want to mess with my $PATH  
constantly to choose between them.

> Then there must also be the same executables with prefix
> (powerpc-linux-gnu-gcc, powerpc-linux-gnu-ld, ...). These must be  
> somewhere in PATH.

No.  This was never a requirement before -- why now?

> Use --cross-prefix=powerpc-linux-gnu-(note the "-" at the end).
> Then pixman would be configured with --host=powerpc-linux-gnu and  
> should find
> the compiler. It won't find the compiler powerpc-linux-gcc when its  
> real name is
> powerpc-linux-gnu-gcc.

No, it's real name is  
/home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu-gcc

-Scott

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Scott Wood]

On 12/13/2012 09:16:58 AM, Gerd Hoffmann wrote:
>   Hi,
> 
> >> A pretty central data structure in qemu (DisplayState /
> >> DisplaySurface) carries a pixman image, not some module which can
> >> easily be made optional.  Just look at the tons of #ifdef'ery you
> >> have to do to get this going.
> >
> > His point is that anything related to DisplayState should be
> > optional.
> 
> We can try, but sprinkling #ifdefs all over the place isn't the way to
> go.  Separate any Display* stuff, say to display.[ch].  Include
> display.h only when needed.  Then not compiling the object files
> will do the trick, and maybe one or two #ifdefs in vl.c.
> 
> At least in theory.  In practice it probably needs some more cleanups  
> so
> it actually works.

That's fine.  This patch was more of a quick hack to show that it's  
possible, and to start a conversation about whether a cleaner approach  
would be accepted if the effort were spent on it.

> And the "not compiling" part brings us back to the "easy way to strip
> down qemu" part.  I'd love to have something (kconfig?) which allows  
> to
> pick which device emulations, block formats, ... I wanna include into  
> qemu.

Yes, kconfig would be very nice.

-Scott

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Stefan Weil]

Am 13.12.2012 16:53, schrieb Scott Wood:
> On 12/13/2012 12:31:14 AM, Stefan Weil wrote:
>> Am 13.12.2012 01:48, schrieb Scott Wood:
>>> It doesn't seem to like my --cross-prefix being a full path rather 
>>> than being a recognized target pattern:
>>>
>>> checking host system type... Invalid configuration 
>>> `/home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu': 
>>> machine 
>>> `/home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc' 
>>> not recognized
>>> configure: error: /bin/bash 
>>> /home/scott/fsl/git/qemu/pixman/config.sub 
>>> /home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu 
>>> failed
>>> make: *** [pixman/Makefile] Error 1
>>>
>>> When I forced --host=powerpc-linux into the pixman configure command 
>>> in QEMU's generated Makefile, it got past that, but it built 
>>> everything with the native compiler:
>>>
>>> checking build system type... x86_64-unknown-linux-gnu
>>> checking host system type... powerpc-unknown-linux-gnu
>>> checking for powerpc-linux-gcc... no
>>> checking for gcc... gcc
>>>
>>> Looking a bit more closely, it seems that it's the QEMU rather than 
>>> pixman's autoconf that is making the bad assumption about the format 
>>> of --cross-prefix (I really wasn't up for wading in autoconf).  
>>> Running basename on cross-prefix and explicitly supplying CC and 
>>> such to pixman would help, though there still should be a way to 
>>> pass in an explicit host tuple if you have an unusually-named 
>>> toolchain.
>>>
>>> -Scott
>>
>> Indeed, --cross-prefixdoes not support absolute path names.
>>
>> I assume that the executables in
>> /home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/binare 
>> without prefix
>> (gcc, ld, ...).
>
> No, they are with prefix, just not in $PATH.  I have more than one 
> "powerpc-linux-gnu" toolchain and I don't want to mess with my $PATH 
> constantly to choose between them.
>
>> Then there must also be the same executables with prefix
>> (powerpc-linux-gnu-gcc, powerpc-linux-gnu-ld, ...). These must be 
>> somewhere in PATH.
>
> No.  This was never a requirement before -- why now?
>
>> Use --cross-prefix=powerpc-linux-gnu-(note the "-" at the end).
>> Then pixman would be configured with --host=powerpc-linux-gnu and 
>> should find
>> the compiler. It won't find the compiler powerpc-linux-gcc when its 
>> real name is
>> powerpc-linux-gnu-gcc.
>
> No, it's real name is 
> /home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu-gcc
>
> -Scott


That are a lot of "no"s. So let me try to be a bit clearer.

You said that you forced --host=powerpc-linux into the pixman configure 
command.
That cannot work, because your host prefix is powerpc-linux-gnu, not 
powerpc-linux.
No wonder that pixman used the native compiler.

A cross prefix which starts with an absolute path (like in your 
scenario) justs
requires adding `dirname "${cross_prefix}"` to PATH and passing
`basename "${cross_prefix%-}" to the pixman configure.

These modifications could be added to QEMU's configure and Makefile
if we really want that. Installing pixman once manually also works
and saves compilation time for repeated builds. That's why I no longer
use internal pixman for any of my cross compilations.

-Stefan

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Scott Wood]

On 12/13/2012 12:58:19 PM, Stefan Weil wrote:
> Am 13.12.2012 16:53, schrieb Scott Wood:
>> On 12/13/2012 12:31:14 AM, Stefan Weil wrote:
>>> Indeed, --cross-prefixdoes not support absolute path names.
>>> 
>>> I assume that the executables in
>>> /home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/binare  
>>> without prefix
>>> (gcc, ld, ...).
>> 
>> No, they are with prefix, just not in $PATH.  I have more than one  
>> "powerpc-linux-gnu" toolchain and I don't want to mess with my $PATH  
>> constantly to choose between them.
>> 
>>> Then there must also be the same executables with prefix
>>> (powerpc-linux-gnu-gcc, powerpc-linux-gnu-ld, ...). These must be  
>>> somewhere in PATH.
>> 
>> No.  This was never a requirement before -- why now?
>> 
>>> Use --cross-prefix=powerpc-linux-gnu-(note the "-" at the end).
>>> Then pixman would be configured with --host=powerpc-linux-gnu and  
>>> should find
>>> the compiler. It won't find the compiler powerpc-linux-gcc when its  
>>> real name is
>>> powerpc-linux-gnu-gcc.
>> 
>> No, it's real name is  
>> /home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu-gcc
>> 
>> -Scott
> 
> 
> That are a lot of "no"s. So let me try to be a bit clearer.
> 
> You said that you forced --host=powerpc-linux into the pixman  
> configure command.
> That cannot work, because your host prefix is powerpc-linux-gnu, not  
> powerpc-linux.
> No wonder that pixman used the native compiler.

It wouldn't have mattered.  There is no powerpc-linux-gnu-gcc in the  
path either.

> A cross prefix which starts with an absolute path (like in your  
> scenario) justs
> requires adding `dirname "${cross_prefix}"` to PATH and passing
> `basename "${cross_prefix%-}" to the pixman configure.

Right...  I'm not thrilled at the idea of build scripts messing with  
$PATH -- normally I deal with autoconf builds by explicitly passing in  
CC and such (and am much happier when I encounter a project such as  
QEMU-until-recently that is fine with just a cross prefix rather than a  
host tuple) -- but the alternative is making the QEMU build scripts  
aware of every build tool than pixman requires.

What I don't want to do is put it in $PATH semi-permanently, in the  
interactive instance of the shell.

> These modifications could be added to QEMU's configure and Makefile
> if we really want that. Installing pixman once manually also works
> and saves compilation time for repeated builds. That's why I no longer
> use internal pixman for any of my cross compilations.

Yes, I could manually install it, though then I get to deal with  
telling the pixman build exactly where to install itself, and repeating  
the process for each toolchain and multilib-variant thereof.

-Scott

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Scott Wood]

On 12/13/2012 01:16:48 PM, Scott Wood wrote:
> On 12/13/2012 12:58:19 PM, Stefan Weil wrote:
>> A cross prefix which starts with an absolute path (like in your  
>> scenario) justs
>> requires adding `dirname "${cross_prefix}"` to PATH and passing
>> `basename "${cross_prefix%-}" to the pixman configure.
> 
> Right...  I'm not thrilled at the idea of build scripts messing with  
> $PATH -- normally I deal with autoconf builds by explicitly passing  
> in CC and such (and am much happier when I encounter a project such  
> as QEMU-until-recently that is fine with just a cross prefix rather  
> than a host tuple) -- but the alternative is making the QEMU build  
> scripts aware of every build tool than pixman requires.
> 
> What I don't want to do is put it in $PATH semi-permanently, in the  
> interactive instance of the shell.
> 
>> These modifications could be added to QEMU's configure and Makefile
>> if we really want that. Installing pixman once manually also works
>> and saves compilation time for repeated builds. That's why I no  
>> longer
>> use internal pixman for any of my cross compilations.
> 
> Yes, I could manually install it, though then I get to deal with  
> telling the pixman build exactly where to install itself, and  
> repeating the process for each toolchain and multilib-variant thereof.

BTW, I use QEMU's --extra-cflags and --extra-ldflags options for  
choosing the multilib variant I'm targeting.  It looks like something  
would need to be added to get those passed into pixman's build as well.

-Scott

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Gerd Hoffmann]

 Hi,

> No, they are with prefix, just not in $PATH.  I have more than one
> "powerpc-linux-gnu" toolchain and I don't want to mess with my $PATH
> constantly to choose between them.

# ls -l /usr/bin/*-gcc
-rwxr-xr-x. 2 root root 264112 Aug 23  2011 /usr/bin/i686-pc-mingw32-gcc
-rwxr-xr-x. 2 root root 268216 Oct 18 18:24 /usr/bin/x86_64-redhat-linux-gcc

I think the second part ("pc" / "redhat") can be choosen pretty freely
when building gcc, so you could name your cross compilers differently,
then have them in PATH and pick by name instead of typing full paths.

> No, it's real name is
> /home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu-gcc

./configure
--cross-prefix=/home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu-
&& make ?

cheers,
  Gerd

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Gerd Hoffmann]

  Hi,

> Yes, I could manually install it, though then I get to deal with telling
> the pixman build exactly where to install itself, and repeating the
> process for each toolchain and multilib-variant thereof.

That part is easy too.  You just need ${cross_prefix}-pkg-config.
A simple two-liner script which sets PKG_CONFIG_PATH, then calls
/usr/bin/pkg-config.  That will not only work for pixman, but all
libraries detected via pkg-config by configure.

cheers,
  Gerd

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Scott Wood]

On 12/14/2012 02:07:23 AM, Gerd Hoffmann wrote:
>  Hi,
> 
> > No, they are with prefix, just not in $PATH.  I have more than one
> > "powerpc-linux-gnu" toolchain and I don't want to mess with my $PATH
> > constantly to choose between them.
> 
> # ls -l /usr/bin/*-gcc
> -rwxr-xr-x. 2 root root 264112 Aug 23  2011  
> /usr/bin/i686-pc-mingw32-gcc
> -rwxr-xr-x. 2 root root 268216 Oct 18 18:24  
> /usr/bin/x86_64-redhat-linux-gcc
> 
> I think the second part ("pc" / "redhat") can be choosen pretty freely
> when building gcc, so you could name your cross compilers differently,
> then have them in PATH and pick by name instead of typing full paths.

For the most part I don't build these toolchains, so that's not an  
option.  Plus, I like having each toolchain fully contained in its own  
directory.  And this worked fine before pixman.

> > No, it's real name is
> >  
> /home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu-gcc
> 
> ./configure
> --cross-prefix=/home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu-
> && make ?

A few more options than that, but basically yes.

I can get past this particular obstacle by doing something like:

(PATH=/home/scott/.../powerpc-linux-gnu/bin:"$PATH" ./configure  
--cross-prefix=powerpc-linu-gnu- ...)
and then
(PATH=/home/scott/.../powerpc-linux-gnu/bin:"$PATH" make)

...but then I run into the problem that --extra-cflags and  
--extra-ldflags don't get passed into pixman.

-Scott

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Scott Wood]

On 12/14/2012 02:13:53 AM, Gerd Hoffmann wrote:
>   Hi,
> 
> > Yes, I could manually install it, though then I get to deal with  
> telling
> > the pixman build exactly where to install itself, and repeating the
> > process for each toolchain and multilib-variant thereof.
> 
> That part is easy too.  You just need ${cross_prefix}-pkg-config.
> A simple two-liner script which sets PKG_CONFIG_PATH, then calls
> /usr/bin/pkg-config.  That will not only work for pixman, but all
> libraries detected via pkg-config by configure.

I already have that (though I can't just use ${cross_prefx} because I  
have multilib variants to account for, so I set PKG_CONFIG=... when  
running configure), due to the glib dependency.  That just lets pixman  
(and other libraries) be found in the QEMU build; it doesn't reduce the  
burden of building and installing pixman for all targets.

-Scott

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Gerd Hoffmann]

On 12/14/12 19:51, Scott Wood wrote:
> On 12/14/2012 02:13:53 AM, Gerd Hoffmann wrote:
>>   Hi,
>>
>> > Yes, I could manually install it, though then I get to deal with
>> telling
>> > the pixman build exactly where to install itself, and repeating the
>> > process for each toolchain and multilib-variant thereof.
>>
>> That part is easy too.  You just need ${cross_prefix}-pkg-config.
>> A simple two-liner script which sets PKG_CONFIG_PATH, then calls
>> /usr/bin/pkg-config.  That will not only work for pixman, but all
>> libraries detected via pkg-config by configure.
> 
> I already have that (though I can't just use ${cross_prefx} because I
> have multilib variants to account for, so I set PKG_CONFIG=... when
> running configure), due to the glib dependency.

That works too.

> That just lets pixman
> (and other libraries) be found in the QEMU build; it doesn't reduce the
> burden of building and installing pixman for all targets.

Yep.  Pixman isn't different from all other build dependencies though.

Once you have pkg-config working for your cross-build setup it should do
fine for all packages qemu depends on.

cheers,
  Gerd

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Gerd Hoffmann]

  Hi,

>> # ls -l /usr/bin/*-gcc
>> -rwxr-xr-x. 2 root root 264112 Aug 23  2011 /usr/bin/i686-pc-mingw32-gcc
>> -rwxr-xr-x. 2 root root 268216 Oct 18 18:24
>> /usr/bin/x86_64-redhat-linux-gcc
>>
>> I think the second part ("pc" / "redhat") can be choosen pretty freely
>> when building gcc, so you could name your cross compilers differently,
>> then have them in PATH and pick by name instead of typing full paths.
> 
> For the most part I don't build these toolchains, so that's not an
> option.

Ok.

> Plus, I like having each toolchain fully contained in its own
> directory.

No need to change that, you can just stick all the directories into the
PATH.  Well, you could if the different compilers would have different
names, thats why I suggested that ...

>> ./configure
>> --cross-prefix=/home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu-
>>
>> && make ?
> 
> A few more options than that, but basically yes.
> 
> I can get past this particular obstacle by doing something like:
> 
> (PATH=/home/scott/.../powerpc-linux-gnu/bin:"$PATH" ./configure
> --cross-prefix=powerpc-linu-gnu- ...)

Why do you need this?  Any tools not picked up correctly if you don't
set the PATH?  Which ones?

> ...but then I run into the problem that --extra-cflags and
> --extra-ldflags don't get passed into pixman.

That should be fixable easily.  Have a patch for that?  If so, please
send to the list.  Otherwise I can have a look.

Why do you need --extra-cflags + --extra-ldflags btw?

cheers,
  Gerd

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Scott Wood]

On 12/19/2012 03:02:13 AM, Gerd Hoffmann wrote:
> On 12/14/12 19:51, Scott Wood wrote:
> > On 12/14/2012 02:13:53 AM, Gerd Hoffmann wrote:
> >>   Hi,
> >>
> >> > Yes, I could manually install it, though then I get to deal with
> >> telling
> >> > the pixman build exactly where to install itself, and repeating  
> the
> >> > process for each toolchain and multilib-variant thereof.
> >>
> >> That part is easy too.  You just need ${cross_prefix}-pkg-config.
> >> A simple two-liner script which sets PKG_CONFIG_PATH, then calls
> >> /usr/bin/pkg-config.  That will not only work for pixman, but all
> >> libraries detected via pkg-config by configure.
> >
> > I already have that (though I can't just use ${cross_prefx} because  
> I
> > have multilib variants to account for, so I set PKG_CONFIG=... when
> > running configure), due to the glib dependency.
> 
> That works too.
> 
> > That just lets pixman
> > (and other libraries) be found in the QEMU build; it doesn't reduce  
> the
> > burden of building and installing pixman for all targets.
> 
> Yep.  Pixman isn't different from all other build dependencies though.

It's different in that I don't actually need any of the functionality  
that depends on it. :-P

> Once you have pkg-config working for your cross-build setup it should  
> do
> fine for all packages qemu depends on.

Again, pkg-config isn't the issue.

-Scott

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Scott Wood]

On 12/19/2012 03:13:34 AM, Gerd Hoffmann wrote:
> >> ./configure
> >>  
> --cross-prefix=/home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu-
> >>
> >> && make ?
> >
> > A few more options than that, but basically yes.
> >
> > I can get past this particular obstacle by doing something like:
> >
> > (PATH=/home/scott/.../powerpc-linux-gnu/bin:"$PATH" ./configure
> > --cross-prefix=powerpc-linu-gnu- ...)
> 
> Why do you need this?  Any tools not picked up correctly if you don't
> set the PATH?  Which ones?

If I don't set the PATH for configure then I get this:
ERROR: "powerpc-linux-gnu-gcc" either does not exist or does not work

> > ...but then I run into the problem that --extra-cflags and
> > --extra-ldflags don't get passed into pixman.
> 
> That should be fixable easily.  Have a patch for that?  If so, please
> send to the list.  Otherwise I can have a look.

I don't have a patch for it currently.

> Why do you need --extra-cflags + --extra-ldflags btw?

For selecting the multilib variant (e500v2 SPE versus normal floating  
point, and eventually I'll probably use it for 32-bit versus 64-bit as  
well).

-Scott

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Gerd Hoffmann]

  Hi,

>> Why do you need this?  Any tools not picked up correctly if you don't
>> set the PATH?  Which ones?
> 
> If I don't set the PATH for configure then I get this:
> ERROR: "powerpc-linux-gnu-gcc" either does not exist or does not work

Any hints in config.log what exactly failed?

>> > ...but then I run into the problem that --extra-cflags and
>> > --extra-ldflags don't get passed into pixman.
>>
>> That should be fixable easily.  Have a patch for that?  If so, please
>> send to the list.  Otherwise I can have a look.
> 
> I don't have a patch for it currently.
> 
>> Why do you need --extra-cflags + --extra-ldflags btw?
> 
> For selecting the multilib variant (e500v2 SPE versus normal floating
> point, and eventually I'll probably use it for 32-bit versus 64-bit as
> well).

Makes sense, ok.

cheers,
  Gerd

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Scott Wood]

On 12/20/2012 12:59:05 AM, Gerd Hoffmann wrote:
>   Hi,
> 
> >> Why do you need this?  Any tools not picked up correctly if you  
> don't
> >> set the PATH?  Which ones?
> >
> > If I don't set the PATH for configure then I get this:
> > ERROR: "powerpc-linux-gnu-gcc" either does not exist or does not  
> work
> 
> Any hints in config.log what exactly failed?

The configure script does lots of compilation tests.  It's not  
surprising that it would fail when the toolchain is not in the PATH,  
when --cross-prefix is changed to no longer specify the absolute  
location.

-Scott

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Gerd Hoffmann]

On 12/20/12 17:19, Scott Wood wrote:
> On 12/20/2012 12:59:05 AM, Gerd Hoffmann wrote:
>>   Hi,
>>
>> >> Why do you need this?  Any tools not picked up correctly if you don't
>> >> set the PATH?  Which ones?
>> >
>> > If I don't set the PATH for configure then I get this:
>> > ERROR: "powerpc-linux-gnu-gcc" either does not exist or does not work
>>
>> Any hints in config.log what exactly failed?
> 
> The configure script does lots of compilation tests.  It's not
> surprising that it would fail when the toolchain is not in the PATH,
> when --cross-prefix is changed to no longer specify the absolute location.

I mean with --cross-prefix specifying the absolute location (so you
don't have to mess with PATH), why does that not work?

cheers,
  Gerd

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Robert Schiele]

On Fri, Dec 21, 2012 at 9:56 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> I mean with --cross-prefix specifying the absolute location (so you
> don't have to mess with PATH), why does that not work?

He actually wrote already previously: The name is thrown into
config.sub, which obviously is confused about this strange
architecture name. If you want to have this supported you need to make
a patch to strip off the path before throwing into config.sub.

Robert

Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support

[Scott Wood]

On 12/21/2012 04:56:05 AM, Robert Schiele wrote:
> On Fri, Dec 21, 2012 at 9:56 AM, Gerd Hoffmann <kraxel@redhat.com>  
> wrote:
> > I mean with --cross-prefix specifying the absolute location (so you
> > don't have to mess with PATH), why does that not work?
> 
> He actually wrote already previously: The name is thrown into
> config.sub, which obviously is confused about this strange
> architecture name. If you want to have this supported you need to make
> a patch to strip off the path before throwing into config.sub.

...and supply additional options/variables to get the pixman configure  
to be able to find the toolchain.

-Scott