I said I'd never blog

Yeah, it's late, we lose an hour, I was tired already, and with a broken back on top of that. I got an external patch for my back (greets to Thom), and of course when coming back home I felt like coding again.

First, I continued to work on the Gtk+ WebKit version of DeforaOS Web Surfer, which is now almost as good as it used to be. By the way, there is even a reference manual using gtk-doc.

Then, thanks to the valuable experience acquired below, I managed to fix the compilation of Xynth in RunningBear, and then I learned to cross-compile glib correctly. I was in a relatively bad mood, anticipating being homesick again in the next couple of weeks, but it turned into a quite productive evening at home :)

While I'm at it, here are a couple of (outdated) screenshots of the Web Surfer, running on hackable:1:

With the GtkHtml2 engine

The same, fullscreen

While reading some code from GNet, I found this:

In file gnet-2.0.8/src/conn-http.c, function gnet_conn_http_conn_parse_response_headers() line 825:

 825 static void
 826 gnet_conn_http_conn_parse_response_headers (GConnHttp *conn)
 827 {
[...]
 867                 /* Note: amazon sends garbled 'Connection' string, but it 
 868                  *  might also be some apache module problem */
 869                 else if (g_ascii_strcasecmp(hdr->field, "Connection") == 0
 870                       || g_ascii_strcasecmp(hdr->field, "Cneonction") == 0
 871                       || g_ascii_strcasecmp(hdr->field, "nnCoection") == 0)

And then while checking if it's true:

$ nc www.amazon.de 80
GET / HTTP/1.1
Host: www.amazon.de

[...]
<!-- MEOW -->

*meow* *meow* *grr* *grr* Riiight...

A while ago, I made this contribution to the Openmoko project: plugging a webcam on the Freerunner. The relevant kernel modules are now compiled by default in the GTA02 kernel from pkg-fso.

The point being, I was recently testing SCTP support on the Openmoko, and I used the same technique to get the kernel module to compile. But then, it kept failing with this error:

insmod: error inserting './sctp.ko': -1 Invalid module format

The problem was that even though my kernel sources did match the one running, the /usr/src/linux/Makefile's EXTRAVERSION parameter was not filled in (typically, with the git commit hash). The kernel then refused to load the module, because of a version mismatch.

The good news is that SCTP seems to work: I got these fine examples to work directly. You'll need to install libsctp-dev to get the necessary include files. The SCTP module is also compiled by default now :)

So, just in case you get this error as well, think about this!

Yeah, it's late again, but I'm addicted to the stuff. Today was frustrating again for a number of reasons:

• grub doesn't load 64-bit NetBSD kernels
• worse, it doesn't load the Xen hypervisor kernel correctly on « big » FFSv1 partitions (mine is 4GB)
• all NetBSD/i386 kernels suddenly panic on my T60's PCMCIA controller (I found an INSTALL-FLOPPY kernel without the issue when breaking my bootloader though)
• you're gonna say NetBSD sucks, but booting my freshly updated Debian Lenny backup USB drive, it refused to recognize my Ethernet card *and* my Wireless card refused to associate anywhere
• as if this wasn't enough, my Intel gigabit card forgot its own MAC address for a while (and then it fixed itself...)
• RunningBear is giving me a hard time with crashes that I cannot explain so far
• gdm (or Xorg) lost my keyboard during three subsequent reboots (it fixed itself again)
• wpi(4) panic'd when it couldn't read its firmware
• and again, there are so many things to do and fix only for work that I hate losing time on meaningless problems like these ones :(

Therefore, I needed to get something to work right. After re-writing half of hackable:1's image generation script (the dependency resolving process), I knew I must have broken the daily builds. I figured a couple days ago that I was sadly right, and I still haven't fixed the key generation with dropbear :(

Anyway, I think I managed to fix crashes with phone-kit and neod in the daily build (permissions to the audio subsystem). I restored the installation of tangogps on the system, and added -n to gpsd's options, which should help with the first fix without exhausting the battery much (tests required). Finally, I got GPS to work on my laptop, using the Openmoko Freerunner over USB. Now I can sleep...

Update: regarding the keyboard problem, I think it's a bug in the modular-xorg-server port for NetBSD, which was starting on top of an existing text console.

Funnily enough, I currently have trouble cross-compiling applications on ARM with my libc. It used to work, but maybe I was doing things differently and I don't remember it (static linking? manual patches? less code?). Anyway, I am coming across these two problems now.

« hidden symbol `__name_here' in /some/library/path.a(_filename.o) is referenced by DSO »

This one made me lose an incredible amount of time. It usually occurs when you overrule the linker's default libraries and object files, because then a plethora of compiler-specific functions are not linked in anymore, whereas often (not always) used in the compiled code. This happens typically with "complex" mathematical functions on RISC platforms, like ARM.

Here is an illustration of the problem:
(compiling as root as I'm testing hackable:1's cross compiler in a chroot)

# ./build.sh CC=arm-linux-gnueabi-gcc all
arm-linux-gnueabi-gcc -o sh token.o scanner.o parser.o builtin.o job.o sh.o  -no
stdlib -L /root/DeforaOS/destdir-Linux-i386/usr/local/lib -Wl,-rpath-link,/usr/l
ocal/lib -l c -l gcc /root/DeforaOS/destdir-Linux-i386/usr/local/lib/start.o
/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld: sh: h
idden symbol `__aeabi_uidiv' in /usr/lib/gcc/arm-linux-gnueabi/4.3.2/libgcc.a(_u
divsi3.o) is referenced by DSO
/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld: final
 link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make[1]: *** [sh] Error 1
make[1]: Leaving directory `/home/khorben/DeforaOS/Apps/Unix/src/sh/src'
make: *** [subdirs] Error 2

In this case, the problem is usually solved by adding either "-l gcc" or "`gcc -print-libgcc-file-name`" to the linking flags (LDFLAGS). However, unlike my other regular platforms (i386, amd64, sparc64) here it wasn't enough. After a lot of head-banging (to be fair, it also comes from the music) I realized that this flag is necessary both when linking the libc *and* the final executable file.

« warning: type and size of dynamic symbol `choose_your_poison' are not defined »

So yeah, problem solved, right? Until the next one :(
(after hacking System/src/libc/src/Makefile so that LDFLAGS are used when linking the libc too)

# ./build.sh CC=arm-linux-gnueabi-gcc all
arm-linux-gnueabi-gcc -o du du.o  -nostdlib -L /root/DeforaOS/destdir-Linux-i386
/usr/local/lib -Wl,-rpath-link,/usr/local/lib -l c -l gcc /root/DeforaOS/destdir
-Linux-i386/usr/local/lib/start.o
/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld: warni
ng: type and size of dynamic symbol `lstat' are not defined
/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld: dynam
ic variable `lstat' is zero size
/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld: warni
ng: type and size of dynamic symbol `stat' are not defined
/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld: dynam
ic variable `stat' is zero size
/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld: du.o(
.text+0x208): unresolvable R_ARM_ABS32 relocation against symbol `lstat'
/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld: final
 link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make[1]: *** [du] Error 1
make[1]: Leaving directory `/root/DeforaOS/Apps/Unix/src/utils/src'
make: *** [subdirs] Error 2

Unfortunately, this one still eludes me: the fault seems to be within my libc, as it compiles fine against the glibc. Here is the incriminated code:

Apps/Unix/src/utils/src/du.c:

 64 static int _du_do(Prefs * prefs, char const * filename)
 65 {
 66         int (* _stat)(const char * filename, struct stat * buf) = lstat;
 67         struct stat st;
 68 
 69         if(*prefs & PREFS_H)
 70                 _stat = stat;
 71         if(_stat(filename, &st) != 0)
 72                 return _du_error(filename);
 73         if(!S_ISDIR(st.st_mode))
 74         {
 75                 _du_print(prefs, st.st_blocks, filename);
 76                 return 0;
 77         }
 78         return _du_do_recursive(prefs, filename);
 79 }

System/src/libc/src/kernel/linux/arm/syscalls.S:

 32 /* macros */
 33 #define SYSCALL(name) \
 34 .global name; \
 35 name:; \
 36         mov     %ip, %r7; \
 37         ldr     %r7, =SYS_ ## name; \
 38         b       _syscall;

System/src/libc/src/syscalls.S:

217 #ifdef SYS_lstat
218 SYSCALL(lstat)
219 #endif

I tried different combinations of extra assembly-level information, like ".type name,@function; \", but only unsuccessfully so far. If you know what I should do, feel free to contact me.