Allow building without graphics support
RFC PATCH 1/1 Allow building without graphics support
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.
---
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
Makefile.objs +5 -2
@@ -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
configure +25 -1
@@ -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)
console.h +4 -0
@@ -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>
hw/Makefile.objs +4 -0
@@ -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
no-console.c new file +8 -0
@@ -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" ); +}
qemu-char.c +2 -0
@@ -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 },
qemu-pixman.c +1 -0
@@ -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)
qemu-pixman.h +4 -0
@@ -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 */
ui/Makefile.objs +2 -0
@@ -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)
ui/vnc.h +4 -0
@@ -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 */
vl.c +12 -2
@@ -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 );
Signature · 1 line
1.7.9.5
Am 12.12.2012 04:18, schrieb Scott Wood:
Quoted 10 lines
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 <[email protected]>---
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.
Quoted 6 lines
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
Quoted 20 lines · Stefan Weil
Am 12.12.2012 04:18, schrieb Scott Wood:
Quoted 10 lines
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 <[email protected]>---
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.Quoted 6 lines
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,
Quoted 7 lines
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
Am 13.12.2012 01:48, schrieb Scott Wood:
Quoted 37 lines · Stefan Weil
Quoted 20 lines
Am 12.12.2012 04:18, schrieb Scott Wood:
Quoted 10 lines
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 <[email protected]>---
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.Quoted 6 lines
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,
Quoted 7 lines
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-gnufailed
make: *** [pixman/Makefile] Error 1When 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:
Quoted 8 lines
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... gccLooking 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
Quoted 16 lines · Stefan Weil
Am 13.12.2012 01:48, schrieb Scott Wood:
Quoted 15 lines
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-gnufailed
make: *** [pixman/Makefile] Error 1When 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... gccLooking 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.
Quoted 7 lines
Quoted 1 line
-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/binarewithout 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.
Quoted 2 lines
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?
Quoted 4 lines
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
Am 13.12.2012 16:53, schrieb Scott Wood:
Quoted 32 lines · Stefan Weil
Quoted 16 lines
Am 13.12.2012 01:48, schrieb Scott Wood:
Quoted 15 lines
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-gnufailed
make: *** [pixman/Makefile] Error 1When 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... gccLooking 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.
Quoted 7 lines
Quoted 1 line
-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/binarewithout 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.
Quoted 2 lines
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?
Quoted 8 lines
Quoted 4 lines
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
Quoted 22 lines · Stefan Weil
Am 13.12.2012 16:53, schrieb Scott Wood:
Quoted 21 lines · Stefan Weil
Quoted 5 lines
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/binarewithout 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.
Quoted 2 lines
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?
Quoted 4 lines
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
Quoted 8 lines
Quoted 1 line
-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.
Quoted 3 lines
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.
Quoted 4 lines
These modifications could be added to QEMU's configure and
Makefileif 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
Quoted 7 lines · Scott Wood
Quoted 3 lines · Stefan Weil
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.
Quoted 8 lines
What I don't want to do is put it in $PATH semi-permanently, in the interactive instance of the shell.
Quoted 4 lines
These modifications could be added to QEMU's configure and
Makefileif 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
Hi,
Quoted 3 lines
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
Quoted 11 lines · Gerd Hoffmann
Hi,
Quoted 1 line
Yes, I could manually install it, though then I get to deal with
telling
Quoted 2 lines
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
Quoted 8 lines · Scott Wood
Quoted 7 lines · Gerd Hoffmann
Hi,
Quoted 1 line
Yes, I could manually install it, though then I get to deal with
telling
Quoted 2 lines
the pixman build exactly where to install itself, and repeating the process for each toolchain and multilib-variant thereof.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 3 lines
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
Quoted 20 lines · Gerd Hoffmann
Quoted 6 lines · Scott Wood
Quoted 5 lines · Gerd Hoffmann
Hi,
Quoted 1 line
Yes, I could manually install it, though then I get to deal with
telling
Quoted 1 line
the pixman build exactly where to install itself, and repeating
the
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
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
Quoted 2 lines
have multilib variants to account for, so I set PKG_CONFIG=... when running configure), due to the glib dependency.
Quoted 8 lines
That works too.
Quoted 2 lines
That just lets pixman
(and other libraries) be found in the QEMU build; it doesn't reducethe
Quoted 1 line
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
Quoted 2 lines
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
Hi,
Quoted 3 lines
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.
Quoted 2 lines
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
Quoted 12 lines · Gerd Hoffmann
Hi,
Quoted 3 lines
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
Quoted 3 lines
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.
Quoted 7 lines
Quoted 2 lines
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
Hi,
Quoted 11 lines
Quoted 8 lines
# ls -l /usr/bin/*-gcc(quoted diff) +0
-2-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-gccI 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.
Quoted 2 lines
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 ...
Quoted 11 lines
Quoted 4 lines
./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?
Quoted 2 lines
...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
Quoted 8 lines · Gerd Hoffmann
Quoted 2 lines
Quoted 2 lines
./configure
--cross-prefix=/home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu-
Quoted 5 lines
Quoted 2 lines
&& make ?
A few more options than that, but basically yes.
Quoted 7 lines
Quoted 4 lines
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
Quoted 5 lines
Quoted 2 lines
...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.
Quoted 1 line
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
Hi,
Quoted 5 lines
Quoted 2 lines
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?
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
...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.
Quoted 7 lines
I don't have a patch for it currently.
Quoted 1 line
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
Quoted 11 lines · Gerd Hoffmann
Hi,
Quoted 1 line
Quoted 1 line
Why do you need this? Any tools not picked up correctly if you
don't
Quoted 4 lines
Quoted 1 line
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 notwork
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
Quoted 6 lines · Scott Wood
Quoted 5 lines · Gerd Hoffmann
Hi,
Quoted 3 lines
Quoted 2 lines
Why do you need this? Any tools not picked up correctly if you don't set the PATH? Which ones?
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
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 workAny 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
Quoted 2 lines · Gerd Hoffmann
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
Quoted 8 lines · Robert Schiele
Quoted 2 lines · Gerd Hoffmann
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
Quoted 3 lines · 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.
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.
Quoted 3 lines
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.
Quoted 4 lines
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
Quoted 11 lines · Gerd Hoffmann
Quoted 3 lines · 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.
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.
Quoted 8 lines
Quoted 1 line
My immediate motivation was that the QEMU-supplied pixman was being
a
Quoted 1 line
pain to cross compile (especially without hacking up the generated
QEMU
Quoted 1 line
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.
Quoted 8 lines
Quoted 2 lines
and in
general it would be nice to not have to carry around graphicalbaggage
Quoted 1 line
when running on hardware that doesn't even have a display (so I was
more
Quoted 1 line
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
Quoted 10 lines · Scott Wood
Quoted 9 lines · Gerd Hoffmann
Quoted 3 lines · 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.
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 2 lines
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
Quoted 14 lines · Gerd Hoffmann
Quoted 13 lines · Scott Wood
Quoted 11 lines · Gerd Hoffmann
Quoted 3 lines · 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.
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.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 2 lines
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
Quoted 2 lines · Alexander Graf
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
Hi,
Quoted 7 lines
Quoted 4 lines
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.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 4 lines
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
Quoted 15 lines · Gerd Hoffmann
Hi,
Quoted 7 lines
Quoted 4 lines
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.honly when needed. Then not compiling the object files will do the trick, and maybe one or two #ifdefs invl.c.
Quoted 6 lines
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 :).
Quoted 11 lines
Quoted 8 lines
Quoted 3 lines
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.
Quoted 7 lines
Quoted 4 lines
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
Quoted 10 lines · Gerd Hoffmann
Hi,
Quoted 7 lines
Quoted 4 lines
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.
Quoted 7 lines
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.honly when needed. Then not compiling the object files will do the trick, and maybe one or two #ifdefs invl.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.
Quoted 3 lines
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
Quoted 10 lines · 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<[email protected]>---
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.
Quoted 7 lines
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.
Am 12.12.2012 17:28, schrieb John Spencer:
Quoted 19 lines · Scott Wood
Quoted 10 lines
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<[email protected]>---
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.Quoted 7 lines
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).
---
Quoted 3 lines
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
Signature · 2 lines
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Quoted 27 lines · Andreas Färber
Am 12.12.2012 17:28, schrieb John Spencer:
Quoted 2 lines · Scott Wood
Quoted 1 line
QEMU is sometimes used in embedded contexts, where graphical
support
Quoted 6 lines
Quoted 6 lines
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<[email protected]>---
There are undoubtedly some rough edges that need to be cleaned upand
Quoted 1 line
Quoted 1 line
other parts of graphics code that could be compiled out -- this is
mainly
Quoted 3 lines
Quoted 3 lines
meant to see what people think of the concept.
My immediate motivation was that the QEMU-supplied pixman was
being a
Quoted 1 line
Quoted 1 line
pain to cross compile (especially without hacking up the generated
QEMU
Quoted 2 lines
Quoted 2 lines
makefiles to pass additional things to pixman's configure), and in general it would be nice to not have to carry around graphical
baggage
Quoted 1 line
Quoted 1 line
when running on hardware that doesn't even have a display (so I
was more
Quoted 3 lines
Quoted 2 lines
inclined to do this than to spend effort fixing the pixman build).
---
Quoted 8 lines
Quoted 3 lines
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
Quoted 3 lines · 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.
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).
Quoted 2 lines
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
Am 12.12.2012 17:47, schrieb Peter Maydell:
Quoted 9 lines · Scott Wood
Quoted 3 lines
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).
Quoted 6 lines
Quoted 2 lines
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
Quoted 8 lines · Andreas Färber
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 settingACLOCAL_FLAGSdid not help. Do we need a more modern pkg-config version than we are testing for?
Another issue seemed to be that ourMakefiledid 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.
Quoted 2 lines
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
Il 12/12/2012 18:09, Andreas Färber ha scritto:
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
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
Quoted 8 lines · Peter Maydell
Quoted 3 lines · 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.
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.
Quoted 7 lines
Quoted 1 line
My immediate motivation was that the QEMU-supplied pixman was being
a
Quoted 1 line
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