From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Cfmvg-0003HP-K1 for qemu-devel@nongnu.org; Sat, 18 Dec 2004 17:20:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Cfmvf-0003Gr-2h for qemu-devel@nongnu.org; Sat, 18 Dec 2004 17:19:59 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cfmve-0003Gm-V6 for qemu-devel@nongnu.org; Sat, 18 Dec 2004 17:19:58 -0500 Received: from [38.113.2.101] (helo=rizzo.jerky.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CfmcI-0003ZU-Q7 for qemu-devel@nongnu.org; Sat, 18 Dec 2004 16:59:58 -0500 Received: from phreaker.net (kubrick.hotpop.com [38.113.3.103]) by rizzo.jerky.net (Postfix) with SMTP id 4A58E36638 for ; Sat, 18 Dec 2004 21:59:57 +0000 (UTC) Date: Sat, 18 Dec 2004 16:59:47 -0500 From: "Jim C. Brown" Subject: Re: [Qemu-devel] get_func() hangs with gcc 3.4.2 on MinGW and WinXP host Message-ID: <20041218215947.GA7207@jbrown.mylinuxbox.org> References: <20041215134754.GA28410@100tka.net> <20041215145903.GA29957@100tka.net> <20041215234503.GA12778@jbrown.mylinuxbox.org> <20041217195627.A38776@saturn.kn-bremen.de> <20041218040428.GA31934@jbrown.mylinuxbox.org> <1103404056.21895.83.camel@aragorn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1103404056.21895.83.camel@aragorn> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: jhoger@pobox.com, qemu-devel@nongnu.org On Sat, Dec 18, 2004 at 01:07:36PM -0800, John R. Hogerhuis wrote: > On Sat, 2004-12-18 at 06:59, Johannes Schindelin wrote: > > The path of least resistance to get there would be to generate op.s > files (using the necessary version of GCC) for all popular CPUs, and > make them part of the build. Then those could be hand optimized over > time as folks have the spare cycles to do it. This would remove specific > gcc version dependencies from the build with little effort. > That works quite well for now. Of course, if qemu is suddenly ported to a new CPU arch, then it is likely that the new op.s file needed would have to be hand coded. Still, a reasonable compromise. > Unless that's a GPL violation (distributing generated code under a > non-GPL license)... don't know about that angle. It is not. GPL only applies to derived code. Generated code is derivied from what you right, not from the gcc source code, and thus the GPL doesn't apply to it. So the op.s files would share the same copyright as the original op.c file. > If that were the case, > the only option along this line would be coding from scratch unless GPL > is acceptable for the core. [QEMU uses mixed licensing and I don't have > it straight in my head, sorry.] QEMU uses BSD/MIT license for the system emulator. It is qemu-user (the linux only one) which is GPL. > > -- John. > > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection.