From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MDOk9-0000Iq-4s for qemu-devel@nongnu.org; Sun, 07 Jun 2009 16:13:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MDOk4-0000DX-KT for qemu-devel@nongnu.org; Sun, 07 Jun 2009 16:13:24 -0400 Received: from [199.232.76.173] (port=35101 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MDOk4-0000DP-H1 for qemu-devel@nongnu.org; Sun, 07 Jun 2009 16:13:20 -0400 Received: from smtp2-g21.free.fr ([212.27.42.2]:43475) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MDOk3-0001oh-J1 for qemu-devel@nongnu.org; Sun, 07 Jun 2009 16:13:20 -0400 In-Reply-To: Subject: Re: [Qemu-devel] Re: User mode linux for Mac OS X with qemu From: "=?utf-8?q?Fran=C3=A7ois?= Revol" Date: Sun, 07 Jun 2009 22:13:26 +0200 CEST Message-Id: <12981784228-BeMail@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ivan Levashew Cc: qemu-devel@nongnu.org > 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=5Fdirectory() 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=5FCHECK=5FLIB(m,sqrt) in configure.ac =3F 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 =3F 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=C3=A7ois.