IcedTea Bootstrap Process
Andrew John Hughes
gnu_andrew at member.fsf.org
Fri Jan 16 20:14:38 PST 2009
2009/1/16 Kurt Miller <kurt at intricatesoftware.com>:
> Andrew John Hughes wrote:
>> 2009/1/16 Kurt Miller <kurt at intricatesoftware.com>:
>>> Hello Andrew,
>>> Andrew John Hughes wrote:
>>>> 2009/1/15 Eric Richardson <ekrichardson at gmail.com>:
>>>>> 2. It seems that there are tons of makefile changes and such brewing on the
>>>>> bsd-ports list that might help us on Mac OS X. What is the mechanism for
>>>>> these to flow into Icedtea?
>>>> There isn't one at present. I think it makes a lot of sense to
>>>> support *BSD in IcedTea proper (including 6). CCing to the BSD
>>>> developers to see if they have any thoughts on this.
>>> Basically it comes down to lack of resources. If I could work full time
>>> on bsd-java many things could be considered like merging our work. With
>>> the available time I have I would like to work towards getting bsd
>>> support included in the main tree.
>> I see your point and agree whole-heartedly. The issue is that there
>> are in effect two main trees: the OpenJDK6 tree (which is being used,
>> patched by IcedTea6, in many GNU/Linux distributions) and the OpenJDK7
>> tree which the BSD tree is currently pulling from. The problem with 7
>> is that, while it gets a lot more TLC from Sun, it could be a couple
>> of years before we see 7 replacing 6 for users and this ties BSD
>> support to the same timeline. For me, it would be nice to see *BSD
>> support sooner than that.
> True. At some point we will get to OpenJDK6 too. For now I'm following
> the standard practice of following current/HEAD/tip to increase the
> likelihood of our work making it in the main tree. If it turns out that
> Sun isn't interested in merging BSD support into the main tree I would
> expect that we will change our focus to OpenJDK6.
Fair enough. I'm not aware of the current situation on *BSD at the
moment, but I would assume that if an implementation is needed, 6
would be the one to go for as has happened with the GNU/Linux distros
(who understandably want to ship a certifiable complete implementation
not a JDK with no specification as yet).
>> Has there been any thought about support from the various BSD
>> distributions and the Free stuff that runs on top of Mac OS X?
> I'm open to any/all support that would allow me to work on open source
> Java full time. I've not approached Apple or the FreeBSD Foundation
> though. I know from past experience the FreeBSD Foundation prefers
> to spend its $ on the certification process and looks to the community
> for the rest of the heavy lifting. I don't have any contacts at Apple
> so I wouldn't know where to start in attempting to approach them with
> the idea.
Well the OpenJDK6 TCK process doesn't cost, though it is effectively a
self-certification process. In the same way that RedHat has, you
and/or FreeBSD could work with the IcedTea community and certify
As to Mac OS X, I wasn't thinking of Apple, but the projects like
Mac/DarwinPorts and fink that exist to provide FOSS packages.
>>> I'm not sure you know this but I've been working on bsd java support
>>> with Sun's JVM for about five years and Greg a few years more then that.
>>> We have merged and merged and merged our work countless times as the JDK
>>> has moved forward. There are about 250 individual files that are patched
>>> to add bsd support. Getting these into the main tree would save us
>>> countless hours of future merging and free us to work on improving the
>>> port with our open-source time.
>> Yes I am aware of this and I'd also like to see things change.
>> However, I'm not sure getting it into the OpenJDK7 tree would help
>> anything, unless Sun are also intending to test and ship their own
>> binaries for BSD platforms.
> I wasn't thinking Sun would embrace supporting all the BSD's officially
> with certified tested binaries. If that happened I would be pleasantly
> surprised and happy. However, getting our work into the main tree would
> help us keep up to date and reduce the mundane time of syncing our work
> at intervals.
> In any case, predicting how things will play out doesn't serve much
> purpose. For now I'm content working at refining our tree to the point
> where a merge could happen.
Sorry, I'm not trying to attack your methods here. It's simply my
impression that Sun may be against maintaining something in the main
tree they don't support, but you probably have a better idea of the
likelihood of it happening.
>>>>> 3. Are there some simple tasks I can do such as patch diffs or something on
>>>>> patches that won't apply?
>>>> You'll need to do that locally. I'm not sure how much help
>>>> contributing these back will be until we know how to proceed with
>>>> this, especially as some will just be because the BSD tree is some old
>>>> OpenJDK7 version.
>>> Actually the bsd-port tree is not old, I'm not sure why you thought that.
>> Sorry, I should have been clearer. I haven't looked at the BSD tree
>> myself but the problems Eric was seeing suggest that the sources he's
>> using from the BSD tree are either outdated or have changed for the
>> BSD port, causing the patches to not apply. In reality, the cause for
>> each patch may be one of these or even both.
> I haven't been following those threads too closely. It looks like he
> is hitting conflicts due to IcedTea trying to patch files that we needed
> to change to add BSD support.
Yes, that's what I'm thinking too.
> Its been a while since I looked at IcedTea closely. The last time was
> probably six months ago. IIRC back then only a RedHat branch of gcc 4.3
> contained the changes needed to build IcedTea. Is that still the case or
> has the gcc/gcj support been merged into gcc mainline?
It was a RedHat backport to 4.1 that was required, prior to the
release of 4.3. Now 4.3 is available, normal GCC/GCJ can be used.
It's also possible to use another Classpath VM, but you obviously need
some way of bootstrapping. The advantage of gcj is a Java
implementation is not needed to build.
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
More information about the distro-pkg-dev