From harmony-dev-return-2245-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Fri Oct 21 15:31:51 2005 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 50421 invoked from network); 21 Oct 2005 15:31:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 21 Oct 2005 15:31:50 -0000 Received: (qmail 75427 invoked by uid 500); 21 Oct 2005 15:31:46 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 75196 invoked by uid 500); 21 Oct 2005 15:31:45 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 75185 invoked by uid 99); 21 Oct 2005 15:31:45 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Oct 2005 08:31:45 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of davanum@gmail.com designates 64.233.170.205 as permitted sender) Received: from [64.233.170.205] (HELO rproxy.gmail.com) (64.233.170.205) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Oct 2005 08:31:44 -0700 Received: by rproxy.gmail.com with SMTP id b11so12154rne for ; Fri, 21 Oct 2005 08:31:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oQ1VEfVa2rd5rGa92T2j2IRVqeeOx54FNVuAtYWBaawaX07IfOS3w9LfG3owAbZmfgHQx9fjAemJAkZlQeqKCdxfAeID7jrpA1Zu+IT9sTkBoecKCfHBwLFqex9R7pBO3dpumUM0CKhzA58YjLYsWvTgv7WlHjHgJkpbVdMrGyI= Received: by 10.11.100.44 with SMTP id x44mr10211cwb; Fri, 21 Oct 2005 08:31:23 -0700 (PDT) Received: by 10.11.122.71 with HTTP; Fri, 21 Oct 2005 08:31:23 -0700 (PDT) Message-ID: <19e0530f0510210831g1dae0af5r72aa6875a88e9a19@mail.gmail.com> Date: Fri, 21 Oct 2005 11:31:23 -0400 From: Davanum Srinivas Reply-To: dims@apache.org To: harmony-dev@incubator.apache.org Subject: Re: Small problems building under cygwin In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <9378830.1129818579673.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> <8cca42d80510201040s76886007n1f22714378405018@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N I believe Express versions are available for download - http://lab.msdn.microsoft.com/express/visualc/default.aspx -- dims On 10/21/05, Geir Magnusson Jr. wrote: > I'd like to be sure that we don't have a barrier to entry by having > to go get commercial software to build the project - by this I mean > a MSVC requirement. I'm happy if windows users can use MSVC if they > want - i.e. if someone supports it - but it can't be the only option. > > geir > > On Oct 20, 2005, at 6:40 PM, Rodrigo Kumpera wrote: > > > Dan, > > > > Suporting multiple SO and hardware configurations is going to be PITA, > > adding compiler to this mix might be overkill. It's true that many > > specialized compiler generate better code than gcc for their platform, > > f.e. ICC, but does that justify the extra effort? > > > > I mean, there are a LOT of stuff we'll need to support many compilers: > > libraries have diferent performance problems and bugs; compilers have > > diferent extensions, standards compliance, assembly sintax and bugs. > > Assembly, for one, is going to be a big issue if we start using native > > threads and need to use memory barriers, we will have the exact same > > x86 code in at&t and intel styles. > > > > It's doable, but will require a LOT of effort to be done. Anyway, I > > don't see much harm in requiring non-linux developers to have instaled > > the gcc toolchain and a bourne shell interpreter, that's a lot less > > than many complex projects require for the build enviroment. > > > > But even then, I'm biased on this subject, as I cannot survive a > > windows machine without cygwin and don't care much for anything else > > but linux. > > > > Have said that, I think having build.sh converted to a .bat script is > > not necessary, only maybe as a subset, that supports only win32/64 on > > MSVC. > > > > > > > > On 10/20/05, Apache Harmony Bootstrap JVM > > wrote: > > > >> > >> Rodrigo, > >> > >> Thanks for your help with these items. I think that > >> it should be a simple matter to have 'config.sh' set > >> a 'win32' path. In fact, there should probably be > >> a map function for that include path so that each > >> configuration can set that subdirectory name to > >> whatever Sun declares it to be for that platform > >> instead of depending on the OS platform name. > >> > >> The '__int64' issue is an interesting one! That's > >> why we're trying out all these porting things. To > >> me, the solution depends partly on a matter of > >> build policy, namely, which compilers do we use? > >> I think that there is a case to be made for supporting > >> MSVC in addition to GCC since it has a large installed > >> base, and a Windows version of the build scripts > >> should be able to support both. I suggest that we > >> could have the compiler as one of the configuration > >> options in 'config.sh' for Windows and CygWin, also > >> for the Windows .BAT file equivalent. What do you > >> think? > >> > >> > >> Dan Lydick > >> > >> > >> -----Original Message----- > >> From: Rodrigo Kumpera > >> Sent: Oct 19, 2005 5:42 PM > >> To: harmony-dev > >> Subject: Small problems building under cygwin > >> > >> I've found a small issue while building under cygwin. > >> > >> I'm using j2sdk 1.4 and gcc 3.4.4 (cygwin). The problems are when > >> building the jni stuff. > >> > >> First it included on gcc find patch "j2sdk\include\cygwin", but it > >> should be "j2sdk\include\win32". > >> > >> Second is when building the included file "jni_md.h" breaks > >> everything > >> as it defines jlong as "__int64" and not "long long". > >> > >> Fixing both is pretty easy, either edit config/config_opts_always.gcc > >> or rename the directory from win32 to cygwin. > >> > >> The second you can either edit jni_md.h and change "__int64" to "long > >> long" or include a define directive, or something like this, in > >> config/config_opts_always.gcc. > >> > >> > >> I'm not sure what would be the best way to fix this on build.sh, as > >> the first issue is related to build enviroment and the second about > >> incompatible compilers ("__int64" works on MSVC and ICC but not gcc) > >> > >> []s > >> Rodrigo > >> > >> > >> > >> > >> Dan Lydick > >> > > > > -- > Geir Magnusson Jr +1-203-665-6437 > geirm@apache.org > > > -- Davanum Srinivas : http://wso2.com/blogs/