[Qemu-devel] User mode linux for Mac OS X with qemu

[Qemu-devel] User mode linux for Mac OS X with qemu

[Ivan Levashew]

(repost)
Hello!

How to build a linux emulator? I can't do it, lots of errors.

When I finally decided to read the documentation, I have found a
surprising statement that linux user mode is for linux hosts only. How
could it be? It's a contrary to QEMU's emulate-anything-on-anything
spirit. I have found that darwin-user is supported on Mac OS X, but it
is of little use since:
a) one can already launch ppc&i386 binaries
b) Nobody targets darwin. Most downloads on sourceforge, nongnu, tigris,
etc. are linux&windows (no darwin!), because free software developers
don't have Macs. And even if they have, Mac OS X is a moving target (so
was Linux in 2000), chances are high that contributed build won't work
due to Apple constantly inventing new incompatibilities.

Linux emulator would be a breath of fresh air for Mac owners.

What do I need to build qemu-linux-user? It seems that I need generic
linux syscall implementation. Do you know where I can get one?

-- 
If you want to get to the top, you have to start at the bottom

Re: [Qemu-devel] User mode linux for Mac OS X with qemu

[Paul Brook]

> How to build a linux emulator?

You can't. Linux usermode emulation only works on linux hosts.

Doing cross emulation is in theory possible, however in practice it gets 
extremely messy for anything other than the trivial case and it's unclear 
whether it's worth the effort, or whether qemu is the appropriate place to do 
this (c.f. WINE).

You can of course run linux inside the system emulator.

Paul

[Qemu-devel] Re: User mode linux for Mac OS X with qemu

[Ivan Levashew]

Paul Brook wrote:
> 
> Doing cross emulation is in theory possible, however in practice it gets 
> extremely messy for anything other than the trivial case and it's unclear 
> whether it's worth the effort, or whether qemu is the appropriate place to do 
> this (c.f. WINE).
> 
One application of it is using Linux/Q instead of wine and java.


Another application (my dream) is deterministic build system. Community 
yell loudly when OpenOffice fails to render 1:1 document from Microsoft 
Office.

However, it is often unnoticed that it's insanely hard to do 1:1 build 
of any randomly picked "open source" build.

Pain starts from the very beginning: configure. It requires a prefix as 
part of its operation. Strange enough that it doesn't ask for command 
line parameters or program launch date or whatever else parameter 
unknown prior to the moment of execution.
Compilers also like putting filenames (including pathes) into binaries.
Autoconf, m4, pkg-config, lots of tools that make build result dependent 
on host configuration.

Every factor commits to denying the fourth freedom, freedom to improve. 
Anybody willing to fix the problem feels like an elephant in a crockery 
shop. One can never be sure that he hasn't forgot some essential 
compiler flag if he can't verify it. Ability to build 1:1 is the 
ultimate verify. If I can build original program 1:1, I can be pretty 
sure that my fix will be the only change I've maid to the compiled program.

It is often the case when I know how to fix something but not doing it 
because building something is never gonna be a short journey.

A virtual machine (kinda Cygwin) might cure some of the diseases. Cygwin 
is a good example here. There are no symlinks on PreVista Windows, but 
Cygwin provides an illusion that they exist.

A virtual machine of my dream have a tweakable namespace (kinda Plan 9) 
because it aids very much in creating a deterministic build environment.

Full-blown VM is
a) way too big gun for precise shooting
b) doesn't provide a tweakable namespace


Nix package manager is deterministic, but it takes some time to port 
something into Nix. Nix puts every compiled package into dedicated 
directory. Every directory needs to be mentioned in include,lib,path 
lists. I think that tweaked namespace is a simpler solution.

-- 
If you want to get to the top, you have to start at the bottom

Re: [Qemu-devel] Re: User mode linux for Mac OS X with qemu

[François Revol]

> Paul Brook wrote:
> >
> > Doing cross emulation is in theory possible, however in practice it
> > gets
> > extremely messy for anything other than the trivial case and it's
> > unclear
> > whether it's worth the effort, or whether qemu is the appropriate
> > place to do
> > this (c.f. WINE).
> >
> One application of it is using Linux/Q instead of wine and java.
>
>
> Another application (my dream) is deterministic build system.
> Community
> yell loudly when OpenOffice fails to render 1:1 document from
> Microsoft
> Office.
>
> However, it is often unnoticed that it's insanely hard to do 1:1
> build
> of any randomly picked "open source" build.
>
> Pain starts from the very beginning: configure. It requires a prefix
> as
> part of its operation. Strange enough that it doesn't ask for command
> line parameters or program launch date or whatever else parameter
> unknown prior to the moment of execution.
> Compilers also like putting filenames (including pathes) into
> binaries.
> Autoconf, m4, pkg-config, lots of tools that make build result
> dependent
> on host configuration.

Well, it's just a design hole in Unices, their FOSS clones (which
failed to improve on their parent there), and the app writers.

Some other OSes have a clean API to find directories... like...
find_directory() on BeOS and Haiku (quite imaginative name), and other
API to load resources from the app's own binary to avoid scattering
files everywhere...
And of course dynamically locating the base app directory to find
related files at launch time...

FreeDesktop.org tried to standardize something alike for Free desktop
OSes but I don't know where it went.

But this has nothing to do with qemu or virtualization, and there is no
need to use a VM just for this as an excuse for lack of design :p

Autocrap indeed fails at many of the points it's trying to address, but
often mostly due to its users, not by itself.
Like, who ever thinks about putting AC_CHECK_LIB(m,sqrt) in
configure.ac ?
Yet it's really painful when porting something to BeOS or Haiku to have
to remove hardcoded -lm everywhere which ought to be probed by
autotools.

Maybe autocrap alternatives like CMake or Scons do this better ? I've
yet to try those.

> Every factor commits to denying the fourth freedom, freedom to
> improve.
> Anybody willing to fix the problem feels like an elephant in a
> crockery
> shop. One can never be sure that he hasn't forgot some essential
> compiler flag if he can't verify it. Ability to build 1:1 is the
> ultimate verify. If I can build original program 1:1, I can be pretty
> sure that my fix will be the only change I've maid to the compiled
> program.

Feel free to try Haiku apps :p

François.

Re: [Qemu-devel] User mode linux for Mac OS X with qemu

[Andreas Färber]

Hello,

Am 06.06.2009 um 23:07 schrieb Ivan Levashew:

> I have found that darwin-user is supported on Mac OS X, but it
> is of little use since:
> a) one can already launch ppc&i386 binaries
> b) Nobody targets darwin.

c) Nobody maintains darwin-user.

It was broken last time I tried, and there's little motivation to fix  
it due to a).

Andreas