Dan, To generate a binary that doesn't depend on cygwin shared lib, for that I use the following combination of flags "-mno-cygwin -Wl,--add-stdcall-alias", the first one is pretty obvious, the second is result of google'ing for a working solution, as I could not make it work without this flag.
I'll look in my cygwin instalation for the header you mentioned. One thing I'm sure is that if we use C++, mixing compilers on the same platform is a huge can of worms. There is not C++ ABI for windows and on linux there are allways some corner cases. On 10/20/05, Apache Harmony Bootstrap JVM <[EMAIL PROTECTED]> wrote: > > Rodrigo, > > An eloquent expression of the sentiments of > many experienced developers! I selected GCC just > for this reason, it is ubiquitously used on many > platforms. Can we use code compiled with CygWin's > GCC compiler on a native Windows platform? I've > done Win32 apps with GCC and MSVC both, but I've > not tried a mix and match between CygWin and > Windows with MSVC and GCC. Comments? > > Anyone else have some experience with this issue? > > I still think we should see what everyone thinks > about MSVC in particular. > > Dan Lydick > > > -----Original Message----- > From: Rodrigo Kumpera <[EMAIL PROTECTED]> > Sent: Oct 20, 2005 12:40 PM > To: [email protected] > Subject: Re: Small problems building under cygwin > > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > Sent: Oct 19, 2005 5:42 PM > > To: harmony-dev <[email protected]> > > 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 > > > > > > > Dan Lydick >
