[Qemu-devel] Re: Build environment image

[Qemu-devel] Re: Build environment image

[Garth Dahlstrom]

Fri, 24 Jun 2005 22:30:40 +0100, Ronald wrote:
> the win32 installers on FreeOSZoo are build on a linux box :)

I recently finished building an QEMU image based build environment for
compiling OpenEmbedded (OpenZaurus, NLUS2, etc)...   In my case it
cross-compiles arm binaries on the x86 QEMU image.

Overall I think a Linux image cross compiling is the way to go for
easy of distribution.

Here are my suggestions:
- Compiling inside QEMU is slow, but ought to be fast enough for
something as small as QEMU (in OE's case you have to compile ~1.2 GB
of source which takes ~1.5 days on an AMD64/Win32 host)

- Use a Debian text-only installation; it needs less then 600MB, zips
to ~150MB and is easy to update.

- Make a separate partition for all build output (i.e. hdb1) - that
way the Guest OS can be maintained and the build can be chucked by
dropping the partition / disk image (hdb).

- Steal the stuff I've done and adapt it... You can find it at
http://www.northern.ca/projects/openembedded/ (the small file being
the build user's directory, the big being the whole image w/ build
user directory)

- If there are any questions about my stuff don't hesitate to ask...
(I get digests of  this list so you might want to cc me directly)

Cheers,

-Garth
(author of QEMUMenu)

-- 
Northern.CA ===--
http://www.northern.ca/
Canada's Search Engine

Re: [Qemu-devel] quick gtk2.c update

[Jim C. Brown]

On Mon, Jun 20, 2005 at 09:58:06PM -0500, jeebs@yango.us wrote:
> Okay, I didn't know that.  (Or I forgot about it.)  That means I was running 
> SDL.
> 
> (That also means that even if it's ends up running in SDL mode, it still 
> wants all those GTK libraries available.  If it isn't using GTK, then it 
> shouldn't need them.)
> 

Perhaps you are right (it is less of an issue in Linux since most workstations
have GTK libraries installed anways ... if you have SDL then you probably have
GTK as well). However, this approach would a) require introducing dlopen()/
LoadLibrary() into qemu in the right places (something I really hesitate to do)
or b) require a link against glib for all cases (not just the GTK case) and
use glib code to handle that (something I am even more relutant to do).

> Using that option now, I'm getting an error when I try to run qemu.
> 
> ***
> Incompatable build!  The code using GTK+ thinks GtkBox is of different size 
> than it actually is in this build of GTK+.
> 
> On Windows, this probably means that you have compiled your code with gcc 
> without the -fnative-struct (or -mms-bitfileds) switch, or that you are 
> using an unsupported compiler.
> ***
> 
> No idea what it really means.  Other than what it actually says.
> 

This is a particularly perplexing error, considering that a) this error should
only show up if you 1) use a MSVC compiled GTK with a mingw/cygwin compiled
app or 2) use a mingw/cygwin compiled GTK with a MSVC compiled app. Since you
used mingw for both, I have not the slighest clue why this occurs. Especially
since I do not use GtkBox anywhere in the gtk code. (I don't use any sort of
Gtk Container period... other than GtkWindow.) There is also c) mixing GTK 2.2
and GTK 2.4 (or possibly GTK 2.4 and GTK 2.6) headers and libraries together
(e.g. including the GTK 2.2 headers in qemu but using the GTK 2.4 libraries
or something).

Technically, it means that the sizes of the structure types don't match, which
means that the library binary (GTK) and the application binary (qemu) are not
compatible.

It is possible that the 2 different mingw environments could have introduced
incompatibilities (a very remote possibility). Perhaps recompiling GTK and
its dependencies inside the new mingw environment would produce valid libraries.
Or it might trash the new environment completely...*shrug*

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] quick gtk2.c update

[jeebs]

> This is a particularly perplexing error, considering that a) this error 
> should
> only show up if you 1) use a MSVC compiled GTK with a mingw/cygwin 
> compiled

I downloaded the libraries and devel files from the link Jernej Simoncic 
recommended.  It does seem to be a main win gtk distrib location.  (As 
somebody pointed out, actually building gtk etc. under Mingw is a pita.  I 
haven't tried, but judging from all the stuff that would be needed to build 
it, I suspect that's true.)

The unzip into the proper mingw directory structure.

> Gtk Container period... other than GtkWindow.) There is also c) mixing GTK 
> 2.2
> and GTK 2.4 (or possibly GTK 2.4 and GTK 2.6) headers and libraries 
> together
> (e.g. including the GTK 2.2 headers in qemu but using the GTK 2.4 
> libraries
> or something).

I'm using the versions recommended and distributed on 
http://www.gimp.org/~tml/gimp/win32/

I get the same error regardless whether I'm using the recommended version or 
the bleeding edge version.

> It is possible that the 2 different mingw environments could have 
> introduced
> incompatibilities (a very remote possibility). Perhaps recompiling GTK and
> its dependencies inside the new mingw environment would produce valid 
> libraries.
> Or it might trash the new environment completely...*shrug*

I don't know how to recompile all that stuff.

I'm just downloading the pre-built devel libraries.

Re: [Qemu-devel] quick gtk2.c update

[Jim C. Brown]

[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]

On Tue, Jun 21, 2005 at 11:27:10AM -0500, jeebs@yango.us wrote:
> I downloaded the libraries and devel files from the link Jernej Simoncic 
> recommended.  It does seem to be a main win gtk distrib location.  (As 
> somebody pointed out, actually building gtk etc. under Mingw is a pita.  I 
> haven't tried, but judging from all the stuff that would be needed to build 
> it, I suspect that's true.)
> 
> The unzip into the proper mingw directory structure.
> 
> I'm using the versions recommended and distributed on 
> http://www.gimp.org/~tml/gimp/win32/
> 
> I get the same error regardless whether I'm using the recommended version or 
> the bleeding edge version.
> 
> I'm just downloading the pre-built devel libraries.

That would explain the error. The pre-build devel libraries would have -mms-bitfields
set (in order to ensure compatibility).

Attached is a simple Makefile.target patch that will turn that option on when
building qemu on Windows. Just apply the patch, reconfigure, and rebuild qemu.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

[-- Attachment #2: Makefile.target.patch --]
[-- Type: text/plain, Size: 334 bytes --]

--- Makefile.target.old	Tue Jun 21 15:42:52 2005
+++ Makefile.target	Tue Jun 21 15:44:17 2005
@@ -211,6 +211,10 @@
 
 #########################################################
 
+ifdef CONFIG_WIN32
+CFLAGS+=-mms-bitfields
+endif
+
 DEFINES+=-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
 LIBS+=-lm
 ifndef CONFIG_USER_ONLY

[Qemu-devel] Build environment image

[Tim Walker]

How difficult would it be to create a (presumably Linux) uniform build 
environment for all targets as a bootable Qemu image?

Re: [Qemu-devel] Build environment image

[Tim Walker]

Is this a bad idea for some reason, or is it just unnecessary? Some 
feedback would be appreciated.

Cheers,

Tim

Tim Walker wrote:

> How difficult would it be to create a (presumably Linux) uniform build 
> environment for all targets as a bootable Qemu image?
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

Re: [Qemu-devel] Build environment image

[John R. Hogerhuis]

On Fri, 2005-06-24 at 18:19 +0100, Tim Walker wrote:
> Is this a bad idea for some reason, or is it just unnecessary? Some 
> feedback would be appreciated.
> 


It's a cool idea, I think. I went through the mingw thing a while back
and it's a PITA. It would be nice to have known working build platform
preconfigured that anyone can download.

I imagine the speed wouldn't be fantastic though. Another possibility:

To make it faster you could integrate the build into a Live CD like Damn
Small Linux (it can easily remaster itself with gcc and whatever other
Debian components you need to build QEMU).

Then any Windows user should be able to boot DSL, run a script to get
latest sources from CVS and build QEMU for Windows saving the .EXE to
their Windows partition.

BTW, one problem with WIndows is that QEMU developers do not have access
to Windows licenses. Might be nice for non-programmers who want to
contribute to donate old licensed copies of Windows for testing work. 

-- John.

Re: [Qemu-devel] Build environment image

[jeebs]

"John R. Hogerhuis"

> BTW, one problem with WIndows is that QEMU developers do not have access
> to Windows licenses. Might be nice for non-programmers who want to
> contribute to donate old licensed copies of Windows for testing work.

Does the ReactOS build work well enough to do Mingw etc. development?


I know you were talking about testing etc., but I was thinking that way you
could have a window'ish environment to do some of the building.

You wouldn't have to do a linux cross compile which might introduce some
other issues or mask some Win32 host build problem.

Re: [Qemu-devel] Build environment image

[John R. Hogerhuis]

On Fri, 2005-06-24 at 14:13 -0500, jeebs@yango.us wrote:
> "John R. Hogerhuis"
> 
> > BTW, one problem with WIndows is that QEMU developers do not have access
> > to Windows licenses. Might be nice for non-programmers who want to
> > contribute to donate old licensed copies of Windows for testing work.
> 
> Does the ReactOS build work well enough to do Mingw etc. development?
> 
> 

I can't say. But even if it were, I'd guess most here would rather work
under Unix-like OS.

> I know you were talking about testing etc., but I was thinking that way you
> could have a window'ish environment to do some of the building.
> 
> You wouldn't have to do a linux cross compile which might introduce some
> other issues or mask some Win32 host build problem.

Nothing wrong with cross compiling, really. Get full power of any
necessary GNU utilities, editors, etc. in their "native environment."
The only trouble is getting mingw, library dependencies, etc. set up in
the first place, and having a standard build image or Live CD is one
possible solution to that problem.

-- John.

Re: [Qemu-devel] Build environment image

[Tim Walker]

Thanks for the replies.

I thought the Live CD was a bad idea until I realised it can still be 
booted under QEMU for non x86 users (Live CDs can be created for other 
platforms - have to pick one otherwise it'd be a nightmare). The 
tradeoff would be speed for x86 users vs ease of image maintenance and 
build environment precision (host processor). There is an appealing 
match between the desired uniformity of build environment and QEMU's aim 
to uniformly emulate different platforms regardless of host. It could 
also be a good test of QEMU itself in the same way GCC self compiles.

Cross compile to Windows from Linux is an unknown quantity to me - has 
anyone tried it yet with QEMU?

Depending on how it's used this could either be a two edged sword or a 
virtuous circle - headlines of "Convenient Build Environment demands 
massive investment of time to keep functional" or "Convenient Build 
Environment helps find QEMU inconsistencies and vice versa". Something 
like that.

Cheers,

Tim

[Qemu-devel] Re: Build environment image

[Ronald]

Le Fri, 24 Jun 2005 22:30:40 +0100, Tim Walker a écrit :

> Cross compile to Windows from Linux is an unknown quantity to me - has
> anyone tried it yet with QEMU?

the win32 installers on FreeOSZoo are build on a linux box :) 
 
> Tim