Older blog entries for Anthony (starting at number 4)


Red Hat is having another world-wide company meeting in Raleigh, NC starting this weekend. Among other things, this means that all the Red Hat gcj hackers/users will get to meet face-to-face for the first time in a while. I'm looking forward to seeing everyone.


This is the nickname for my LiveCD experiment. Everything is working well enough now that it's basically useful as a distcc server. Just pop it in a cdrom and it goes. Now I've been thinking of how to support remote native compilation of java code with gcj. The distcc approach doesn't work because it depends on sending preprocessed source with no external dependencies to the build machine. This won't work with gcj, so my current thinking is to just hook into the build machine's C library by LD_PRELOADing a library like this in order to generate queries back to the user's machine for other sources (jar, class, etc). Will this work?

I like this approach, even for C/C++, since it may enable speculative compilation on the build machines during idle times (different debug or optimization levels).

Why Managed C++ on mono with Open64 will fail

I was going to leave it at one blog entry today, but it seems that blogs are the only forum in which to respond to other blogs.

Miguel de Icaza's recent blog entry on Managed C++ and Mono is really misguided. He proposes that Open64 and the old "new" WHIRL representation present a path to Managed C++ on mono. I attended the Open64 User Forum last year, and this is what I learned. Some of it may be dated now, but a quick look at the mail archives is unconvincing.

  • Open64 has a fractured developer community.
    The open source community around Open64 technology forked a number of years ago (see ORC), so there doesn't appear to be canonical upstream sources anywhere. And while a couple of big companies are still building production compilers based on the Open64 technology, there is no meaningful interaction with the open source community ("where do we send patches?" was an oft heard refrain).
  • Open64 has a small user community.
    This compiler has no x86 back-end, which severely limits the potential user community. I believe that this really inhibits the ability of the non-commercial developers from producing a trusted compiler.
  • The GNU compiler front ends hacked into Open64 are way old.
    This is where I'd expect you'd want to borrow the most code for a Managed C++ tool. But don't expect help from the GCC community to fix this. The FSF has decided that the technology used in Open64 (persistant intermediate representations) is harmful to their goals.
I don't really mean to be so harsh on the Open64 project. In many ways, the technology is a decade ahead of GCC, and a number of successful commercial compilers have been built out of it -- but it is not a successful open source project. The only measure by which you might claim it is successful is as a research platform for generating interesting papers. And now GCC is bound to catch up in that arena, given the new SSA-based infrastructure.

So, if you really cared about Managed C++, then you would look to GCC and the new SSA infrastructure for an answer. On the other hand, you might just want to consider GCJ and CNI.

Shared libraries and "the desktop"

With all of the recent discussion of GNOME desktop programming technologies, I'm really surprised that ability-to-generate-shared-libraries doesn't ever come up. I mean, really. Take a look at some of these library sizes:

  • GNU Classpath
  • java-gnome
  • Xerces, xalan and friends
Now imagine a number of featureful applications jitting their own copies of these things (or just loading their non-shared AOT compiled assemblies). Not a pretty picture.

This is just one more reason gcj rocks.

Work and taxes...

...have consumed much of my time this past week. I dropped the ball on some of my free-time-hacking comittments (sorry Mark :-) However, I did find a few minutes to mess with...

LiveCD experiment

distcc is installed, and it appears to work. I've even got tomcat starting up and serving the start of a nice web app. The tomcat in Fedora is pretty cool. I was able to drop a third party JSP tag library into the right place and it just worked. The only complicated bit (for me, at least) was figuring out all of the various apache and mod_jk2 configury. It probably would have been much easier had I read instructions somewhere.


Tom recently started a thread on rolling new libffi releases. There's been some good input so far, and I finally responded today. Constant pressure from Tom and Mark, as well as this discussion, is helping motivate me into action.

Embedded Systems Conference

I spent most of last week in San Francisco at the Embedded Systems Conference for Red Hat. We were there promoting GNUPro tools and our embedded services. Several people searched me out to discuss gcj, and how they've been tracking its progress for use in their products. While most gcj activity is happening on Linux and Windows these days, few people know that gcj was originally developed for embedded systems hackers. Our initial target was an embedded MIPS-based platform. It was fun to talk about gcj at the show. Perhaps it will be coming to a video slot machine near you... :-) We also had some boxes running gcj-built-Eclipse as an IDE for embedded development, and it performed very well.

LiveCD experiment

Last night I managed to build a Fedora Core 2 test2 based LiveCD specifically for turning idle PCs into temporary distcc clients. This isn't a new idea, but the existing hacks I've seen weren't exactly what I was looking for. It boots properly and I get a shell, which I consider partial victory. I'll try installing distcc next.

24 Dec 2002 (updated 24 Dec 2002 at 06:56 UTC) »
gcj 3.3

There have been a couple of major milestones in gcj-land these past two days:
  • libgcj.dll works on Windows. Thanks to Chris Faylor for pointing out recent binutils progress which made this possible.
  • Eclipse runs with gij for a non-trivial amount of time. tromey, mjw, aph and others have really done a great job.
3.3 is looking really good right now. I was able to bring up xscale-elf out of the box, and frv-elf with a little bit of work. Now, if we can get the mingw32 DLL bits into 3.3 it will be perfect. Hopefully somebody will pick this up.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!