Another day learning the Linux way...

| 5 Comments
My client has decided that we should ignore the video driver problem and press on with the proof of concept using the external VGA screen as a display. So this week was spent learning about building software for a machine running a minimal Linux installation using libc 2.3.2 on a machine running a proper distro using libc something else...

The first job was to evaluate a couple of small web browsers, dillo and viewml; their choice, not mine (not that I have any issues with the choice, I just didn't do any research around it). Our target device has 32mb of disk space so we can't afford stuff that takes up a lot of space.

Since neither option was 'easy' I bounced between the two as problems came up. The first thing I did was install a pre-built version of dillo on my dev box from an rpm. I figured I'd put the executable and the dynamic libs that it needed on the target machine and see what happened. That's when I was introduced to the wonderful world of 'different versions of libc'... This is much more like DLL hell than the rpm problem I had last week ;) Due to the wonders of dynamic linking most things directly, or indirectly, rely on a dynamicly linked version of the c runtime library, libc. Of course, everything that a program links to that links with libc has to agree on the same version of libc... My pre-built version of dillo for Fedora Core 4 was linked with a different version of libc to the version that's available on the target machine... To follow the advice that James Antill gave in his comment to my earlier post I'd need to find a prebuilt version of dillo for the correct version of libc...

I briefly considered going back to building my own version from source and decided against it, for now, instead I grabbed the Fedora Core 1 ISO images and installed them in a virtual machine. Fedora Core 1 uses the same version of libc that my target device does... Around this time I realised that even though my target device is x86 Linux and my development box is x86 Linux I'm still, effectively, cross-compiling - I expect there's a better way to do this than the way I'm currently doing it but we need a proof of concept by the end of the week and right now the 'hack around the problems' approach appears to be working well enough.

So, whilst I kicked off the Fedora 1 download I took a look at Pixil's Viewml browser. This had the, by now, standard list of prerequisites to be downloaded and built. They all built fine and then the pixil stuff failed because it didn't like my version of GCC. Now, call me old fashioned but I like an OS where, if you need two versions of a compiler, you can just install one version in one place and one version in another. I've been working with Microsoft's Visual Studio like that since they brought out the .Net ones... I've had all versions of Visual Studio installed since they came out and I compile my code with most of them on a regular basis. It doesn't seem quite so simple on Linux... Of course I haven't investigated it fully but... Well, it failed the 'Nike' test... I couldn't 'just do it'...

The Pixil code didn't compile because my newer compiler was stricter than the one they'd used. I did some web searches and found their newsgroup. I found some patches but not a full set. They spoke of making a set of patches available; that was in October. They didn't seem to have done so. That was pretty much enough of a reason for me to drop that particular piece of software from our evaluation. File it in the 'not really as active as we'd like' bin.

So it was back to Dillo. By now I'd downloaded and installed Fedora 1, found that there wasn't an RPM for Fedora 1 (or if there was one, failed to find it), grabbed the source and built it. It ran fine on my VMWare box but of course that had all the requirements installed. Requirement number 0 was X11...

After a while I'd managed to work out that I needed a minimal X11 system on the device. I'd downloaded some prebuilt binaries and started to do a trial and error thing to copy just the bits I needed onto the device. More of my unix heritage was coming back; ldd is your friend, as is the log file that the X server creates... After a little while I realised that a couple of the crashes I was getting could possibly be due to the fact that the binaries were not necessarily built JUST for the i386... I wasn't 100% sure but I pulled down the sources, adjusted the compiler flags and made sure that I built a version with a makefile that knew I wanted it to work on a real 386. I then did the same for the browser itself.

Time passes...

By the end of yesterday I got to the point where I had the basic X background and cursor briefly appearing as xinit ran the browser on the device and then something horrible happened to the display and things died. At this point we pulled the plug until we either get new hardware with a supported display driver or the manufacturer of our existing hardware comes up with a working driver...

The whole experience was fun. I learned a lot. I remembered a lot and I realised why Linux and Open Source appeal to hackers. There are just so many problems to solve. And, after all, the fun is in solving the problems...

5 Comments

What a lot of Linux advocates ignore is that the dependency problem in Linux is way worse than Windows. There is nobody insuring backward compatiblity. I've been dealing with libc issues since, well, since 1995.

Way to often the solution is "build from source." But if your target looks nothing like your development machine, that isn't so easy.

I love Open Source, and Linux, but I think they both have a long way to go in usability.

What do you do if your target isn't like your dev box and you cant just create a 'near enough' dev box in a virtual machine? I assume you have to treat it as a full blown cross compile and set up a more complicated build environment? Looking at a few of the FAQs and readme files it seems that it's maybe not even that simple and that the makefiles need to be playing ball... Since this looks like something that is pretty common why hasn't someone come up with a soft linked based 'dev environment switch' system ?

The fact that I can't easilly install two versions of a compiler and then build a system with each of them, side by side, seems, well, somewhat crap ;)

Not sure I understand your problem with compilers! In your makefile you can just set:

GCC=/opt/gcc_4.0.2/bin/gcc

then

debug:
$(GCC) $(OBJS)

etc.

Bear in mind the makefile will inherit your environment you could just do:

set GCC=/opt/etc/etc ; export GCC
make

before building, or have different target names per compiler. It does just 'do it' ;)

There was some issue with where libraries and headers were picked up from. There was some issue with rpm's not allowing me to install the second version of GCC because there was already a version installed and that it wasn't possible to select where to install the second version even if I did manage to force it into letting me because it told me that the rpm in question wasn't relocatable.

That's where you want to do all that make configure make install malarkey ;) rpm's aren't that good imho.

Leave a comment