Fixing a build failure

I haven’t posted in a while, so I figured I’d just give a sample of the kinds of things I deal with as an Ubuntu developer.

When a Wine developer wants to implement support for playing mp3 files, the smart thing to do is to use a software library, in this case mpg123.  Wine is a good example of a large and still growing piece of software with a similarly expanding list of dependencies.

It’s my job to make sure all these bits work well together so that Wine can be built in a complete way for you – without mpg123, Wine would have to be built without full support for mp3s, and sound on some apps would simply break.  Sometimes this means packaging software that isn’t in the distribution yet.  Usually it means fixing bugs, and here we can see the true strength of the open source approach.

It starts with a bug report

I was ready to put out a Wine release with its new mpg123 support, but Wine wasn’t building on 64 bit.  This was a case where the mystery was more interesting because it was only partially broken: 32 bit worked perfectly.

I knew right away that it was probably an Ubuntu-specific issue, although other distributions (especially Debian) might also be affected.  I filed a bug upstream to try and nail down the specifics.  Everyone shares their relevant expertise here: a Wine developer notes that it’s a mismatched symbol-header problem, I figure out the cause is Ubuntu’s unexpected use of 32-bit headers on 64-bit systems, a community member provides a temporary workaround patch, an mpg123 developer tells why things were the way they were and how Ubuntu+Wine was the first to expose this problem, and Alexandre Julliard says what he’d ultimately like as a best practice.

This sort of collaboration is exactly what Open Source is about.  Everyone involved could just go to the same bug tracker and simply get to work – it didn’t matter that all 6 of us were in different continents working for different companies on different projects.  Everything is laid bare, easy to see and thus easy to fix.

Getting it done

At the end of the day, getting the fix out to users is what actually matters.  It’s really disappointing when great code like mp3 support just doesn’t happens because of something silly like an out of date distribution library.

So, that’s the final step in the chain – the mpg123 developer puts out a new version of mpg123, and then I have to package that up and put it into the latest Ubuntu alpha.  This is where Launchpad’s ability to have a single bug exist against multiple packages becomes especially helpful: by filing a launchpad bug I could track the changes I had to make to all 3 packages (mpg123, ia32-libs, and then wine).

Technical details for the interested

It’s worth noting that this bug could have been prevented entirely if Ubuntu had proper multiarch support.  Multiarch means the ability to install 32-bit packages directly onto a 64-bit system, rather than having to use special separate 32-on-64 packages like ia32-libs.  Multiarch has been a slow, gradual redesign under development in Debian and Ubuntu for years now, and it just barely missed the Lucid cycle.

This leaves us with the current implementation, which can at best be described as “a tremendous hack.”  32-bit libraries from needed packages are manually added to a giant list.  Then they’re processed by a script and all thrown into one gigantic, 600+ megabyte package named ia32-libs.  This means that any program which needs 32-bit compatibility (such as Wine) has to depend on this massive source package, and any time a single component changes it needs to be manually updated.

However, ia32-libs contains only the library files, not the header files, so when you build a 32-bit application on 64-bit Ubuntu you’re actually building with the header files installed from the 64-bit version of the package.  This is normally fine, as most header files are identical across different architectures, however this wasn’t the case with mpg123.  So we were using a 32-bit library that had different symbols than the 64-bit header file, and the build then fails with symbol errors.

There are quite a few applications for 64-bit Ubuntu that need to make use of 32-bit libraries for various reasons, however Wine is by far the most dominant.  This makes me, the one responsible for Wine, also the official babysitter of ia32-libs and similarly broken packages.  Wine is special in a way, though, as unlike other applications there is no way to fix it by just making it 64-bit — Wine will always need 32 bit libraries in order to run 32 bit Windows applications, which will remain incredibly common for at least another decade.

5 Comments

ImmanuelFebruary 25th, 2010 at 11:50 pm

good post, and also I’m glad this bug is fixed now :)

ArthurFebruary 26th, 2010 at 11:04 am

Thank you for all your hard work. Ubuntu is the best!

FreonFebruary 26th, 2010 at 3:05 pm

Does that mean this bug is fixed?
http://bugs.winehq.org/show_bug.cgi?id=20277

YokoZarFebruary 26th, 2010 at 5:59 pm

Freon, it does look like the “no mpg123 lib” part of that bug is certainly solved.

fate63January 15th, 2011 at 8:58 pm

I haven

Leave a comment

Your comment