Content tagged deforaos http://people.defora.org/~khorben/place/category/35/deforaos en Releasing a new snapshot of the DeforaOS smartphone environment on hackable:1 khorben@defora.org (khorben) Mon, 30 Aug 2010 14:57:56 +0200 http://people.defora.org/~khorben/place/blog/95/Releasing-a-new-snapshot-of-the-DeforaOS-smartphone-environment-on-hackable:1 http://people.defora.org/~khorben/place/blog/95/Releasing-a-new-snapshot-of-the-DeforaOS-smartphone-environment-on-hackable:1 Of course, my current plan is to investigate and fix this as soon as possible (with a new snapshot). Yet, among the changes since the last release of the environment, you will already find:
  • a new finger keyboard, with popup keys (and using Gtk+' theme)
  • the addition of a phone log;
  • preferences windows for the phone application;
  • the return of the background picture, and a preferences window to easily change it;
  • last but not least, the final version of my initial attempt at SMS encryption.
With this, I will continue my work on the user experience:
  • fix and update the web browser (broken since the switch to Debian testing);
  • continue improvements to the finger keyboard (bigger keys, multiple layouts)
  • nicer Gtk+ theme and artwork if I manage (screenshots!)
  • more actual tests and usability improvements to the phone application;
  • power management;
  • GPRS support.
I have also begun to implement an application to configure access to wireless networks, with wpa_supplicant's help. It will take another while though.

For more information, as always, check either http://www.defora.org/, the IRC channel of hackable:1 (#hackable1 on Freenode), the respective mailing-lists (devel@lists.defora.org, hackable1-dev@lists.hackable1.org...) or even, feel free to contact me directly of course: http://people.defora.org/~khorben/place/wiki/13/Contact

And before I forget, the snapshot itself is announced and available there: http://www.defora.org/os/news/3394/New-snapshot-of-the-DeforaOS-smartphone
]]> Improvizing a talk at Debienna khorben@defora.org (khorben) Thu, 26 Aug 2010 18:54:19 +0200 http://people.defora.org/~khorben/place/blog/91/Improvizing-a-talk-at-Debienna http://people.defora.org/~khorben/place/blog/91/Improvizing-a-talk-at-Debienna
It was called "hackable:1 (and then more)", and I really appreciated this opportunity. See you guys!

[1] http://www.debienna.at/
[2] http://trac.hackable1.org/
[3] http://people.defora.org/~khorben/papers/h1more/h1.html
]]> News from the hackable:1 front khorben@defora.org (khorben) Fri, 30 Jul 2010 16:00:45 +0200 http://people.defora.org/~khorben/place/blog/89/News-from-the-hackable:1-front http://people.defora.org/~khorben/place/blog/89/News-from-the-hackable:1-front https://www.defora.org/os/news/3380/Snapshot-of-the-DeforaOS-smartphone-available-for-tests

It directly benefits from the recent switch to Debian Squeeze/testing, as the default version of Debian on which hackable:1's development is now based. Like before, images are generated daily and found here:
http://build.hackable1.org/

Last but not least, you may have heard of OsmocomBB, a Free Software GSM Baseband software implementation:
http://www.osmocom.org/
Good news is, I have started to package it for use within hackable:1. A few things are left to be fixed before they can be pushed automatically online, but I have been able to cross-compile libosmocore and the layer23 set of tools already.
]]> The DeforaOS smartphone environment khorben@defora.org (khorben) Sat, 12 Jun 2010 21:46:31 +0200 http://people.defora.org/~khorben/place/blog/88/The-DeforaOS-smartphone-environment http://people.defora.org/~khorben/place/blog/88/The-DeforaOS-smartphone-environment
It's probably relevant to begin with some background information about all this, although even then it's difficult to know where to start. 

Reinventing the wheel
For some reason I found the urge to start an Operating System project of my own, which began with a modified version of Debian GNU/Linux [2]. This goes as far back as 2001, which may seem like yesterday to many experienced UNIX users, but was just a year after my first installation of a distribution on my own computer. This turned into a LFS-based project [3], before becoming the DeforaOS project as it is today [4], with more or less the goal to re-implement a complete kernel and user environment.

That is to say, you may see a pattern here, and remind me that such time may be better spent improving the existing projects. While I would definitely agree that many Open Source projects need help (quite logically, otherwise I wouldn't have started my own), I will briefly summarize the reasons behind my choices:
  • I am having fun, and learning in the process;
  • back then, I did not have the technical means (eg cheap Internet access), let alone political power to influence much of the things I really wanted;
  • with my projects evolving, I stuck with this work and choices rather than give it all up;
  • frankly I still do not see myself having any political power now in the community, to do what I really want anyway;
  • last but not least, I am essentially trying to implement a different design, which I believe is worth a try.
Of course this doesn't mean that I always make the same choices as a professional [5]. This experience has always been useful, even though a compromise in design I made to implement a working solution unfortunately hasn't succeeded to date [6]. But I have then been focusing a full year on the hackable:1 project instead [7], with a few releases along the way. 

The Openmoko Freerunner
This is clearly another illustration of the "reinventing the wheel" approach. Why go all the way and create an Open Source smartphone from scratch [8]? It sure must be tedious, and from my experience and the information I have obtained in the process, I can say it sure was. And I can't say it was a clear, undisputed success either.

I'll be honest: I never liked the device itself. I found it ugly and bulky at best. I encountered the most annoying hardware bugs and subsequent frustration rushes. No need to mention the community fragmentation, which didn't help either. But today still, it sure has its uses, and is actually useful in plenty of ways. 

Coding again
Burning out, having new opportunities, I parted ways and resumed work as a security consultant instead [9]. I could afford to take a first break in far-away land (thanks a.) and have fun creating software again, rather than feel like a packaging robot for what seemed to me as being broken code anyway.

I could manage to get a few bugs fixed in my current Operating System of choice (NetBSD [10]), and then turn a few more sub-projects of DeforaOS to be good enough that I began to (finally) use many of them on a daily basis. 

The motive(s)
Owning a Sharp Zaurus [11] for a few years, I had already been thinking about an embedded version of the desktop environment while writing it. But I could do better; I could take my revenge on the Openmoko Freerunner instead. Still bitter from the outcome of my efforts while working with the device, I was convinced that I could do better. Be it true or not, as always there is only one way to know: trying it hard, whatever the reason.

After a quick glance at the Openmoko community, to no surprise I found its activity to be declining. Maybe this is not true and I was simply expecting it, but I think it's fair to say that the hardware is aging. Nonetheless, combined with hackable:1 it has the advantage to easily letting me run my own native environment. This is certainly not true of the more popular mobile platforms. 

Trying a different way
As mentioned, I thought I could turn this phone into something more useful than it already was. This was based on the following assumptions, based on my personal appreciation:
  • the existing projects are over-engineered;
  • they have no global coherence concerning usability;
  • they are often developed as regular applications, regardless of the hardware constraints.
Better then, some interesting and unusual features of the hardware are available and documented [12], some of which could turn into interesting security developments. I cannot pretend to have actually been able to do better, or implement all these fancy features, especially within this other month break; but here is where I am now. 

The DeforaOS embedded desktop environment
First, I have spent some time improving and adapting my existing desktop applications to fit the Freerunner. I won't copy and paste what I have already written about it [13]. Instead, here is a summary of its current status:
  • neither hardware buttons are required (nor currently used) for regular operation, as everything can be done on-screen;
  • both panels are fully functional, with an integrated application launcher, and displaying the clock, hardware status (including registration, signal level and operator) and of course an application switcher;
  • the on-screen keyboard is fast, although definitely not finger-friendly at the moment (xkbd embedded in the panel), and will be re-implemented from scratch;
  • the contextual menus (as offered through a Gtk+ extension) could be more intuitively found;
  • the file manager is functional, but could be better integrated with the freedesktop.org standards;
  • the clipboard and drag&drop features from the same project could be improved as well;
  • the homescreen functionality cannot be enabled at the moment due to how matchbox-window-manager handles it;
  • DeforaOS' own window manager is not mature enough to be used instead at this point;
  • the latest versions of the web browser cannot be packaged on hackable:1 at the moment, as it depends on a more recent version of WebKit.
I think this reflects quite well what is to be expected there. 
The DeforaOS smartphone environment
Meanwhile, I have implemented a complete telephony application from scratch [14]. The design goals were:
  • use Gtk+ and the glib libraries in C, and only relying on them and DeforaOS' libDesktop;
  • embed the GSM daemon directly inside it;
  • implement the core application with all the required functionality built-in (eg contacts, messages, phone calls, preferences...)
  • let this application be as reactive as possible (eg single process)
  • extend it through optional plug-ins;
  • support hardware modems as broken as on the Openmoko Freerunner.
It's still far from being eligible as a regular mobile phone sold with a contract, but as of today this first set of goals was mostly met. Some essential features are still missing:
  • adding, editing and deleting contacts;
  • maintaining a phone log;
  • sending DTMF codes during calls;
  • storing the messages sent;
  • support for delivery reports;
  • preferences dialogs;
  • entering the PUK/PIN2/PUK2 codes;
  • switching to data mode;
  • call forwarding...
Most of them are not challenging anymore, and are just a matter of taking a few hours this and there to get them done. 
Where is gets interesting
One of the first parts I believe I should emphasize in this post is the plug-in support. First, it allows full integration with the actual, underlying hardware platform with all the code clearly separated. This is the case on the Openmoko, where:
  • a first plug-in takes care of supporting profiles, by requesting a ring tone, triggering the vibrator and so on;
  • the hardware plug-in catches these events and turns the relevant components on and off.
Secondly, it allows extending the functionality in lots of different ways, from PulseAudio support to DBUS and potentially FSO integration [15], without mentioning webcams, GPS positioning [16] and then more.

And there's more. 

SMS encryption
One of the first additional security features I have been thinking about is SMS encryption [17]. While not being specific to the Freerunner, it is certainly an interesting platform for such a feature. My current implementation, while not being cryptographically strong at the moment, can already be demonstrated as a working Proof-of-Concept [18].

More than that, it is maybe time to think about a common, interoperable way to implement this feature. It looks like things could be moving towards this direction, with new projects emerging like TextSecure [19]. 

Cell tracking and geotagging
Not unlike some other phones, but probably in a more accessible way, the Freerunner supports an "engineering mode". It is basically a monitoring mode [20][21], much like the one on your regular 802.11abgn wireless card (except you can't sniff traffic, yet [22][23][24]).

While not being as featureful and polished as kismet [25], my current implementation (couple of days old) can already illustrate this concept. 

The future
With a project as promising as Osmocombb [26] able to run on the Freerunner, I can only let you guess where all of this can be going. There are still many things to be done with this hardware, and of course I am also hoping to run my software on other devices as well, like the ones from ROAD [27], GizmoForYou [28], Nokia [29], Glofiish [30], HTC [31] and Palm [32] among others.

If you would feel interested in any of this, do not hesitate to let me know [33]. Better, you can use the development infrastructure directly [34]. I will welcome your feedback and ideas, free patches and hardware, consider contracted projects. 

Thank yous
To conclude, I have omitted one of the reasons behind all of this in this post. I had the pleasure to be invited to the Nokia Hackfest in Berlin mid-March this year [35], and then be honoured with a free N97 and N900 device. They have both proven very helpful while developing this software already.

Of course there's a number of people and projects who are also a great help to me every day. I can only hope to be helpful to you, too. Cheers!

[1] http://www.defora.org/os/news/3363/Introducing-the-DeforaOS-smartphone
[2] http://www.debian.org/
[3] http://www.linuxfromscratch.org/
[4] http://www.defora.org/
[5] http://people.defora.org/~khorben/cv.en.html
[6] http://runningbear.org/
[7] http://trac.hackable1.org/
[8] http://www.openmoko.org/
[9] http://www.duekin.com/
[10] http://www.netbsd.org/
[11] http://www.trisoft.de/slc3200.htm
[12] http://wiki.openmoko.org/wiki/Neo_1973_and_Neo_FreeRunner_gsm_modem
[13] http://www.defora.org/os/news/3362/DeforaOS-as-an-embedded-desktop-environment
[14] http://www.defora.org/os/project/3343/Phone
[15] http://www.freesmartphone.org/
[16] http://realtimeblog.free.fr/
[17] http://www.cryptosms.org/
[18] http://www.passageenseine.org/hackevents/confidences-par-sms
[19] http://www.whispersys.com/
[20] http://nobbi.com/monitor/index.html
[21] http://www.gnokii.org/screenshots.shtml
[22] http://www.gnuradio.org/
[23] http://cryptome.org/jya/crack-a5.htm
[24] http://reflextor.com/trac/a51
[25] http://www.kismetwireless.net/
[26] http://bb.osmocom.org/
[27] http://www.road.de/
[28] http://www.gizmoforyou.net/
[29] http://www.nokia.com/
[30] http://www.glofiish.com/
[31] http://www.htc.com/
[32] http://www.palm.com/
[33] http://people.defora.org/~khorben/place/wiki/13/Contact
[34] http://www.defora.org/os/project/bug_list/3343/Phone
[35] http://www.youtube.com/watch?v=5jW3VDqvzLs
]]> A graphical mixer for NetBSD khorben@defora.org (khorben) Fri, 18 Dec 2009 18:16:29 +0100 http://people.defora.org/~khorben/place/blog/75/A-graphical-mixer-for-NetBSD http://people.defora.org/~khorben/place/blog/75/A-graphical-mixer-for-NetBSD
Some background information: NetBSD [2] has an audio API of its own [3][4], which I'll call "audioio" because it sits in /usr/include/sys/audioio.h [5]. It seems to be based on Solaris' historical audio sub-system, but I've always had a hard time obtaining decent documentation about Solaris [6] on the web so I'll skip this part.

To the point: NetBSD thankfully provides an OSS emulation layer [7]. Unfortunately, it is outdated (version 3), and assumes that controls are always fixed and resemble those of the "historical" cards (eg the SoundBlaster 16 [8]). Therefore, fewer and fewer controls are actually functional, since they are implemented in totally different ways in newer sound cards.

Therefore, until recently, I had to use the native NetBSD tool, mixerctl [9], to operate with the mixer (volume controls). Just for fun, I'll paste here what it looks like on my laptop: 
$ mixerctl -av
outputs.spdif.source=os  [ os adc ]
outputs.lineout.source=dac  [ dac mixerout ]
outputs.lineout.mute=off  [ off on ]
outputs.lineout=240,240  delta=4
record.lineout=85,85  delta=85
outputs.lineout.dir=output  [ input output ]
outputs.lineout.boost=off  [ off on ]
outputs.lineout.eapd=on  [ off on ]
outputs.headphones.src=dac  [ dac mixerout ]
outputs.headphones.mute=off  [ off on ]
outputs.headphones=124,124  delta=4
outputs.headphones.boost=off  [ off on ]
outputs.mono.mute=off  [ off on ]
outputs.mono=124  delta=4
record.mic=85,85  delta=85
outputs.linein.source=dac  [ dac mixerout ]
outputs.linein.mute=off  [ off on ]
outputs.linein=124,124  delta=4
record.linein=85,85  delta=85
outputs.linein.dir=output  [ input output ]
outputs.mono.source=dac  [ dac mixedmic linein mixerout lineout mic2 ]
inputs.beep.source=digitalbeep  [ digitalbeep beep ]
inputs.beep.mute=off  [ off on ]
inputs.beep=119  delta=17
inputs.dac.mute=off  [ off on ]
inputs.dac=248,248  delta=8
inputs.mic.mute=off  [ off on ]
inputs.mic=120,120  delta=8
inputs.linein.mute=off  [ off on ]
inputs.linein=120,120  delta=8
record.source=mixedmic  [ mixedmic linein mixerout mono cd lineout mic2 aux ]
record.mute=off  [ off on ]
record.master=255,255  delta=17
outputs.mic2.source=dac  [ dac mixerout ]
outputs.mic2.mute=off  [ off on ]
outputs.mic2=124,124  delta=4
record.mic2=85,85  delta=85
outputs.mic2.dir=output  [ input output ]
inputs.lineout.mute=off  [ off on ]
inputs.lineout=120,120  delta=8
inputs.aux.mute=off  [ off on ]
inputs.aux=120,120  delta=8
inputs.mic2.mute=off  [ off on ]
inputs.mic2=120,120  delta=8
inputs.cd.mute=off  [ off on ]
inputs.cd=120,120  delta=8
record.mixedmic.mute1=off  [ off on ]
record.mixedmic.mute2=off  [ off on ]
playback.mode=analog  [ analog spdif ]
That's 49 lines of cryptic controls indeed. To be fair, the mixerctl tool is great for scripts, but totally impractical when poking at the different controls just to understand what they mean and how they work.

Although, looking at the code, I found the API very interesting. In fact, it describes the different controls in terms of groups of values, sets or switches, providing their different names every time. I then imagined that I could generate an interface on the fly, based on Gtk+ [10], using sliders, checkboxes and radio buttons. It doesn't solve the whole problem understanding your own sound card, but I guess it would be much more practical this way.

It looks like this:
I think it's quite funny actually :)

To conclude about alternatives, I don't know how well pulseaudio [11] and others are working on NetBSD, since I'm not an avid GNOME/KDE/XFCE/etc fan. But if you have any idea or suggestion about mine, please do not hesitate! [12]

[1] http://www.defora.org/os/project/display/3305/Mixer
[2] http://www.netbsd.org/
[3] http://netbsd.gw.com/cgi-bin/man-cgi?audio+4+NetBSD-5.0
[4] http://netbsd.gw.com/cgi-bin/man-cgi?audio+9+NetBSD-5.0
[5] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/audioio.h?only_with_tag=netbsd-5
[6] http://www.opensolaris.com/get/index.jsp
[7] http://netbsd.gw.com/cgi-bin/man-cgi?ossaudio+3+NetBSD-5.0
[8] http://en.wikipedia.org/wiki/Sound_Blaster_16
[9] http://netbsd.gw.com/cgi-bin/man-cgi?mixerctl+1+NetBSD-5.0
[10] http://www.gtk.org/
[11] http://pulseaudio.org/
[12] http://people.defora.org/~khorben/place/wiki/13/Contact
]]> gputty on Sourceforge khorben@defora.org (khorben) Sun, 29 Nov 2009 19:07:20 +0100 http://people.defora.org/~khorben/place/blog/67/gputty-on-Sourceforge http://people.defora.org/~khorben/place/blog/67/gputty-on-Sourceforge
Even though I'm not actively working on this project anymore, I was really pleased to see that is has some kind of community, with people spontaneously working on it. Therefore, I have created a project for gputty on Sourceforge [4], where hopefully more people will volunteer for this project!

Just create yourself a Sourceforge account and tell me [1] if you want access to the project. I'll happily let you contribute :)

I have already moved the project page and downloadable files to Sourceforge, and I have every intention to move its upstream source code repository over there as well. I suppose it'll be using the default SVN source code management platform in place [5].

To conclude, I'll let you know my current plan about gputty:
  • release 1.0.0 mostly as-is, to mark this event;
  • plan 2.0.0 to be using OpenSSH' own configuration files: ~/.ssh/config instead of the INI-style parser from DeforaOS.
I didn't really look for it, but I don't know any other tools doing it. Could be neat.
[1] http://people.defora.org/~khorben/place/wiki/12/About
[2] http://people.defora.org/~khorben/projects/gputty/
[3] http://www.gputty.de/
[4] http://sourceforge.net/projects/gputty/
[5] svn co https://gputty.svn.sourceforge.net/svnroot/gputty gputty
]]> Working on the VFS again khorben@defora.org (khorben) Sat, 31 Oct 2009 19:02:46 +0100 http://people.defora.org/~khorben/place/blog/66/Working-on-the-VFS-again http://people.defora.org/~khorben/place/blog/66/Working-on-the-VFS-again
Among the significant changes:
  • introduced distinct interface definition files; currently expected to be installed in $(SYSCONFDIR)/AppInterface, they contain the definitions of the calls exported (they were previously hard-coded within the library)
  • the exported functions are still obtained automatically with dlopen(NULL)+dlsym(), but they now need to be prefixed with the name of the interface implemented (and a '_' character)
I haven't had the time to thoroughly test these changes, but I hope I will get to use this code again soon. I really want to be playing with the VFS and monitoring applications again.

About the VFS in particular, the directory listing functions should be implemented soon. Finally :)
]]> DeforaOS Project khorben@defora.org (khorben) Thu, 30 Jul 2009 00:20:16 +0200 http://people.defora.org/~khorben/place/bookmark/50/DeforaOS-Project http://people.defora.org/~khorben/place/bookmark/50/DeforaOS-Project ]]> Surfing and cross-compiling glib for RunningBear khorben@defora.org (khorben) Sun, 29 Mar 2009 05:24:06 +0200 http://people.defora.org/~khorben/place/blog/4/Surfing-and-cross-compiling-glib-for-RunningBear http://people.defora.org/~khorben/place/blog/4/Surfing-and-cross-compiling-glib-for-RunningBear
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:
http://people.defora.org/~khorben/share/DeforaOS/surfer/surfer-hackable1-daily-gtkhtml.png

The same, fullscreen:
http://people.defora.org/~khorben/share/DeforaOS/surfer/surfer-hackable1-daily-gtkhtml-fullscreen.png
]]> Some issues with the libc on ARM khorben@defora.org (khorben) Wed, 18 Mar 2009 01:18:28 +0100 http://people.defora.org/~khorben/place/blog/8/Some-issues-with-the-libc-on-ARM http://people.defora.org/~khorben/place/blog/8/Some-issues-with-the-libc-on-ARM
« 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.
]]>