Skip to main content

Cygwin support for JDK build.

20 replies [Last post]
vijayj
Offline
Joined: 2004-10-26

In our ongoing effort to ease the setup of windows build, we are looking into some of the tools used. Currently we have been using MKS on our windows platform. We know that MKS is not free, so we have been thinking about supporting Cygwin to build our product. We would like to know if there is any interest from the community to use Cygwin.

Please let us know your comments.

Thanks,
Vijayan.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mthornton
Offline
Joined: 2003-06-10

> Also with Windows, the install locations are not very
> predictable, and we need to use the pathnames without
> any spaces in their names, e.g. "C:/Progras~1/"
> rather than "C:/Program Files/".

Are you aware that not all Windows systems have the "DOS" paths? Surely it is about time that you were able to work with paths containing spaces.

blbrown
Offline
Joined: 2005-04-20

Just for the build and any of the ALT_ variables I used, I used the DOS convention. I tried to avoid using any spaces in any of my variables. It looked like only one instance. I guess I could have tried the unix style/cygwin convention. Never thought about it.

blbrown
Offline
Joined: 2005-04-20

Just curious, I am new to this, does the Cygwin support work with Win32 - b32. I am changing all kinds of variables. I can't even get the sanity target to work.

kellyohair
Offline
Joined: 2004-09-03

It should work. Can you provide some more specifics on what you have had to change?

There are lots of variables that may need to change regardless of MKS or CYGWIN. One of our big issues with Windows builds is that we can't re-distribute many of the software bundles needed to build, and Windows needs more of these than Solaris and Linux. Also with Windows, the install locations are not very predictable, and we need to use the pathnames without any spaces in their names, e.g. "C:/Progras~1/" rather than "C:/Program Files/".

Anyone with solutions/ideas for these specific problems should speak up.

blbrown
Offline
Joined: 2005-04-20

I will post to the main forum page.

hou_zhenyu
Offline
Joined: 2004-03-08

I built b29 with VS.NET 7.1. It seems that in "register_i486.hpp"

class XMMRegisterImpl: public AbstractRegisterImpl {
public:
...

// construction
friend XMMRegister as_XMMRegister(int encoding) { return (XMMRegister)encoding; }
}

should be changed to:

class XMMRegisterImpl: public AbstractRegisterImpl {
public:
...
friend XMMRegister as_XMMRegister(int encoding);
...
};

inline XMMRegister as_XMMRegister(int encoding) { return (XMMRegister)encoding; }

timbell
Offline
Joined: 2003-06-10

You have it exactly. See bug-id 6240371
"register_i486.hpp: error C3767: 'as_XMMRegister'
matching function is not accessible"

Fixed and Integrated in b30

philwalk9
Offline
Joined: 2003-06-24

Cygwin support is very valuable!

mlk
Offline
Joined: 2004-03-04

Yes please.

vijayj
Offline
Joined: 2004-10-26

As a part of the peabody build improvements, we have fixed all the CYGWIN issues in the mustang workspace and expanded support for hotspot and deploy workspace. Now, you could successfully build hotspot, j2se and deploy workspace using CYGWIN from the control workspace.

set ALT_UNIXCOMMAND_PATH=C:/cygwin/bin instead of mks bin directory or Cygwin should be in your PATH variable.

We have tested against cygwin 1.5.12-1 version. Those who are interested in CYGWIN and windows i586 build, please give a try and let me know your comments.

Thanks,
Vijayan.

mturk
Offline
Joined: 2005-01-23

Hi,

Cygwin 1.5.13-1.
You will need to rename or delete the link.exe
from coreutils package.

It builds but I had to change couple of things,
since I'm using VS.NET
In Sanity.gmk changed
REQUIRED_CCVER = 13.10.3077
REQUIRED_LINKVER = 7.10.3077
REQUIRED_UNICOWS_LIB_SIZE = 2320414

Any way to set the minimum version required?

Needed to change the net_util_md.h because MSVC7+ has
defined sockaddr_in6, as well as commenting define
from Inet6AddressImpl.c

Also X_API.h has different defines from
for INT8 etc, so I've just comment those.
Think those can be omitted if INSANE is set.

Noticed that org/omg has some strange local dates,
so there is a warning if locale is not ANSI.
Hashtable.cpp(129) (and few others)
have a warning:C4345 on POD object type,
so INSANE=true was need for build.

I'll try to make some benchmarks with official
b26 binaries and mine, to see if recent MSVC
is faster.

All an all, pretty cool, and no need to spend
the $5K for MKS. Think they'll hate you :)

Regards,
Mladen

timbell
Offline
Joined: 2003-06-10

Thanks for posting your build notes, and congratulations! on getting a build.

I am working on the code changes to make the JDK source base palatable to both VC6 and VC7 compilers (bug-ID 6210740). I'm almost finished, but more testing is needed.

mturk
Offline
Joined: 2005-01-23

Yes, but all that build process is too complex thought.
Since Java5 is needed to build Java6, how about creating
a real cross platform build system using Java itself?

By that I mean using Ant. I mean, why would you need
OS abstraction when you already have one with Java?
It simply doesn't not make sense to use all that bogus
cross platform tools when you already have Java inplace.

Regards,
Mladen Turk

timbell
Offline
Joined: 2003-06-10

> Yes, but all that build process is too complex
> thought.

We agree. This complexity is felt internally as well as externally. We can't tear apart the current system because we are producing our weekly builds with it. The improvements will be done in small steps so the all the developers (both internal and external), and integrators can keep up.

> Since Java5 is needed to build Java6,

We have plans to allow a build to bootstrap from a JDK 6.0 binary snapshot release, so you won't need the Tiger/5.0 bits if you don't want them.

> how about creating
> a real cross platform build system using Java
> itself?
>
> By that I mean using Ant. I mean, why would you need
> OS abstraction when you already have one with Java?
> It simply doesn't not make sense to use all that
> bogus
> cross platform tools when you already have Java
> inplace.

The OS abstraction provided by the JDK means there is a certain amount of native code in the JDK itself. Any new build system will need to be able to deal with the mixed environment (.java, .c, .cpp sources) before we can use it. We don't want to trade one set of problems for another, so this part of the project requires further study.

bjb
Offline
Joined: 2003-06-12

> > how about creating
> > a real cross platform build system using Java
> > itself?
> >
> > By that I mean using Ant. I mean, why would you
> need
> > OS abstraction when you already have one with
> Java?
> > It simply doesn't not make sense to use all that
> > bogus
> > cross platform tools when you already have Java
> > inplace.
>
> The OS abstraction provided by the JDK means there is
> a certain amount of native code in the JDK itself.
> Any new build system will need to be able to deal
> l with the mixed environment (.java, .c, .cpp
> sources) before we can use it. We don't want to
> trade one set of problems for another, so this part
> of the project requires further study.

What are the tradeoff of ant for GCC compilation (assuming the GCC will be de default contributor compiler) ?

See http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=6...

You can handle configurations, you can call a program with whatever set of parameters configured ....

Obviously, no direct migration of makefile to ant is there, to the ant script will have to be built.

Any ant&makefile guru in da place to build this ?

IMHO, any dependency that are outside GCC should be removed, obviously this involve a lot of cleanup. But at the end you will have a clean application that will be much more easy to maintaint and to port to any other platform.

I also think, personally, that native code should be avoided at any cost and that we should also try to migrate all the native code that this possible to some java equivalent.

kellyohair
Offline
Joined: 2004-09-03

In it's most simple form, Makefiles can easily be replaced with just about anything. The J2SE Makefiles and what they need to do goes well beyond simple Makefiles and simple native compilations. You should not under-estimate any effort involving re-writing or converting any build system.

Java compilation might very well be done with ant, but if the end result is the same, and if the typical Makefile for a package called java.foo.bar looks as simple as:

BUILDDIR = ../..
PACKAGE = java.foo.bar
PRODUCT = java
include $(BUILDDIR)/common/Defs.gmk
AUTO_FILES_JAVA_DIRS = java/foo/bar
include $(BUILDDIR)/common/Classes.gmk

What is the big deal?
What does replacing the above with an ant script do for us?

Now, maybe I'm biased, but I find the ant xml scripts as ugly as sin, and hard to read, write, and understand.

I'm not against making large or earth-shaking changes to the build system, but it needs to come with some kind of benefit and not be done just because people think that Makefiles are antiques or ant scripts are beautiful.

I have recently added the AUTO_FILES_JAVA_DIRS capability to the JDK Makefiles (Build 32), and we will allow the addition of ant scripts as an alternative build mechanism for developers, but using ant as the only build mechanism and displacing the Makefiles is not something that can easily happen or even makes sense to do.

It's been suggested that we should use javamake instead of javac, and that does come with a benefit, it could provide a more accurate incremental build, making sure all the proper java sources are recompiled. [Currently the Makefiles suffer the same flaw as the ant scripts, they don't properly re-compile all the java sources that need to be compiled.]

I just want to make sure that any large scale change comes with some large scale benefits.

bjb
Offline
Joined: 2003-06-12

Clearly it is a "JUST DO IT"™ feature !
#1 It will remove dependency on MS dev tools.
#2 It will not force us to buy a dev license.
#3 It might ease the C code to be consistent accross platform (because of GCC "everywhere").

rcleveng
Offline
Joined: 2003-07-08

+1

Please use cygwin over MKS.

cowwoc
Offline
Joined: 2003-08-24

+10

Moving from MKS to Cygwin would make a huge difference! In general, phasing out as many commercial products as possible should be encouraged (simply from the point of view of accessibility to people who want to build the code).

Gili

nikolaymetchev
Offline
Joined: 2005-01-17

This is probably not entirely relevant but in January 2005's edition of Dr Dobbs (http://www.ddj.com) there is an article on cross platform builds. Whomever is in charge of the build might want to read it. It is written by John Graham-Cumming.