Older blog entries for twisti (starting at number 17)

Finally: OpenJDK 6 b11 on Alpha Linux

Yesterday I finally was able to finish the OpenJDK build on Alpha Linux. I'm not exactly sure what really fixed the build, but definitely adding the missing compiler flags again (with -D_LITTLE_ENDIAN) helped. When Gary commited his zero work we lost some architecture dependent flags, I'll re-add them ASAP.

And now to the fun:

Finally a new release... and another one.

Pheew! After more than one year our codebase was ready to get a new release... so I did. And then I noticed, because I was a bit out of practice doing a release, it had a few bugs. Yeah, of course :-( So I made another one, called 0.99.1.

With official OpenJDK Java runtime library support we are now heading to a 1.0.0 release. I hope that one will be without bugs...

Changing Emacs' default font

I wanted to change the default font of Emacs without setting properties in the .Xresources. The window font can be changed with:

M-x customize-face RET default RET

I set it to misc-fixed with height 113.

The menubar font can be changed with:

M-x customize-face RET menu RET

I'm still searching for the correct font, but in my .Xresources it was:

Emacs*menubar.font: Lucida
Which OpenSolaris package contains pkg-config?

It took me some time to figure that out, because it's not installed per default from CD and I haven't upgraded the whole system yet (because I'm still running on my swap partition).

It's in SUNWgnome-common-devel. Pheew...

Password storage of nwamd(1)

Because I didn't know my WIFI password from the top of my head, I entered the wrong one when nwamd(1) was asking for it. But it didn't ask again. So I wondered where the passwords are stored.

After some google'ing I found the correct command:

# dladm show-secobj

Then I could delete the stored password with:

# dladm delete-secobj nwam-twisti-xx.xx.xx.xx.xx.xx

It seems dladm(1) is just a frontend for text files. The passwords are actually stored in /etc/dladm/secobj.conf.

Switch to OpenSolaris?

I'm thinking about to switch to OpenSolaris on my Apple mac mini. I installed Indiana on my Linux swap partition to see how it works.

Right now I'm trying to get suspend working (http://blogs.sun.com/randyf/entry/solaris_suspend_and_resume_how), but I'm not sure it will work with this version:

May 28 21:19:41 workstation genunix: [ID 314293 kern.info]
device pci8086,27a2@2(display#0) keeps up device
sd@0,0(sd#0), but the latter is not power managed
OpenJDK on ARM

Today I pulled myself together and tried to build IcedTea for ARM again. I had two options: to build it natively on an ARM board or try to cross-compile it. I decided to try the cross-compile approach.

The build did not fully finish, because I don't have ALSA libraries in my cross-build enviroment, so I just took an j2re-image from an x86_64 build and replaced


with the cross-compiled one and copied


into the x86_64 j2re-image.

And it works!!!

$ uname -m
$ java -version
java version "1.6.0"
IcedTea Runtime Environment (build 1.6.0-b06)
CACAO (build 0.98+svn, JIT mode)

(btw. this output calls 10273 Java methods)

Now I'm testing applications like DaCapo and most benchmarks of DaCapo already pass in small size.

IcedTea on Alpha

After some problems with the architecture define in OpenJDK's build system, today I got the stuff built. At least the ECJ-poured one:

$ uname -m
$ openjdk-ecj/build/linux-alpha/bin/java -version
java version "1.7.0"
IcedTea Runtime Environment (build 1.7.0-b24)
CACAO (build 0.98+svn, JIT mode)
$ openjdk-ecj/build/linux-alpha/bin/java -cp ~/cacao/ HelloWorld
Hello World!

Let's see if I get the whole stuff built...

undefined reference to `__tls_get_addr'

I had some problems to get IcedTea compiled on our i386, x86_64 and powerpc64 boxes. It turned out to be the -z def linker option and the glibc version used. A little google'ing revealed the fix. Just add the AS_NEEDED directive as shown below:

$ cat /usr/lib64/libc.so 
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED (
/lib/ld64.so.1 ) )
5 Sep 2007 (updated 23 Jul 2008 at 07:37 UTC) »
HotSpot's verifier not verifying

Yesterday I found the problem why we get a VerifyError when running Eclipse with CACAO-OpenJDK, while HotSpot does not. It's again the MagicAccessorImpl class.

Snippet from sun/reflect/MagicAccessorImpl.java (I overlooked that when debugging the access-check bug):

    The bug fix for 4486457 also necessitated disabling
    verification for this class and all subclasses, as
opposed to just
    SerializationConstructorAccessorImpl and subclasses, to
    having to indicate to the VM which of these
    stub classes were known to be able to pass the verifier. 

Finding these magics is really a pain...

8 older entries...

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!