harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: Small problems building under cygwin
Date Fri, 21 Oct 2005 12:28:59 GMT
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.


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
> On 10/20/05, Apache Harmony Bootstrap JVM <bootjvm@earthlink.net>  
> 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 <kumpera@gmail.com>
>> Sent: Oct 19, 2005 5:42 PM
>> To: harmony-dev <harmony-dev@incubator.apache.org>
>> 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

View raw message