The Linux Experiment

As you may be able to tell from my recent, snooze-worthy technical posts about compilers and makefiles and other assorted garbage, my experience with Linux from Scratch has been equally educational and enraging. Like Dave, I’ve had the pleasure of trying to compile various desktop environments and software packages from scratch, into some god-awful contraption that will let me check my damn email and look at the Twitters.

To be clear, when anyone says I have nobody to blame but myself, that’s complete hokum. From the beginning, this entire process was flawed. The last official LFS LiveCD has a kernel that’s enough revisions behind to cause grief during the setup process. But I really can’t blame the guys behind LFS for all my woes; their documentation is really well-written and explains why you have to pass fifty --do-not-compile-this-obscure-component-or-your-cat-will-crap-on-the-rug arguments.

Patch Your Cares Away

Read more…

If you run into the following error trying to build LFS from a Ubuntu installation:


make[1]: *** No rule to make target `/mnt/lfs/sources/glibc-build/Versions.all', needed by `/mnt/lfs/sources/glibc-build/abi-versions.h'. Stop.


The mawk utility installed with Ubuntu, and symlinked to /usr/bin/awk by default does not properly handle the regular expressions in this package. Perform the following commands:


# apt-get install gawk
# rm -rf /usr/bin/{m}awk
# ln -snf /usr/bin/gawk /usr/bin/awk


Then you’re just a make clean; ./configure –obnoxious-dash-commands; make; make install away from success.

So my base Gentoo installation came with Gnome 2.3, which while solid, lacks a lot of the prettiness of Gnome’s latest 3.2 release. I thought that I might like to enjoy some of that beauty, so I attempted to upgrade. Because Gnome 3.2 isn’t in the main portage tree yet, I found a tutorial that purported to walk me through the upgrade process using an overlay, which is kind of like a testing branch that you can merge into the main portage tree in order to get unsupported software.

Since the tutorial that I linked above is pretty self-explanatory, I won’t repeat the steps here. There’s also the little fact that the tutorial didn’t work worth a damn…

Problem 1: Masked Packages

#required by dev-libs/folks-9999,
required by gnome-base/gnome-shell-3.2.1-r1,
required by gnome-base/gdm-3.2.1.1-r1[gnome-shell],
required by gnome-base/gnome-2.32.1-r1,
required by @selected,
required by @world (argument)
>=dev-libs/libgee-0.6.2.1:0 introspection
#required by gnome-extra/sushi-0.2.1,
required by gnome-base/nautilus-3.2.1[previewer],
required by app-cdr/brasero-3.2.0-r1[nautilus],
required by media-sound/sound-juicer-2.99.0_pre20111001,
required by gnome-base/gnome-2.32.1-r1,
required by @selected,
required by @world (argument)
>=media-libs/clutter-gtk-1.0.4 introspection

This one is pretty simple to fix: you can add the lines >=dev-libs/libgee-0.6.2.1:0 introspection and >=media-libs/clutter-gtk-1.0.4 introspection to the file /etc/portage/package.accept_keywords, or you can run emerge -avuDN world –autounmask-write to get around these autounmask behaviour issues

Problem 2: Permissions

--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE "/var/log/sandbox/sandbox-3222.log"

VERSION 1.0
FORMAT: F - Function called
FORMAT: S - Access Status
FORMAT: P - Path as passed to function
FORMAT: A - Absolute Path (not canonical)
FORMAT: R - Canonical Path
FORMAT: C - Command Line

F: mkdir
S: deny
P: /root/.local/share/webkit
A: /root/.local/share/webkit
R: /root/.local/share/webkit
C: ./epiphany --introspect-dump=
/var/tmp/portage/www-client/epiphany-3.0.4/temp/tmp-introspectSfeqBO/functions.txt,
/var/tmp/portage/www-client/epiphany-3.0.4/temp/tmp-introspectSfeqBO/dump.xml
--------------------------------------------------------------------------------

This one totally confused me. If I’m reading it correctly, the install script lacks the permissions necessary to write to the path /root.local/share/webkit/. The odd part of this is that the script is running as the root user, so this simple shouldn’t happen. I was able to give it the permissions that it needed by running chmod 777 /root/.local/share/webkit/, but I had to start the install process all over again, and it just failed with a similar error the first time that it attempted to write a file to that directory. What the fuck?

At 10pm at night, I couldn’t be bothered to find a fix for this… I used the tutorial’s instructions to roll back the changes, and I’ll try again later if I’m feeling motivated. In the mean time, if you know how to fix this process, I’d love to hear about it.

I’ve decided to try and upgrade my LFS system to the latest version of KDE (4.7.3 as of the time of this writing) and correspondingly needed to upgrade phonon-backend-gstreamer. Unfortunately, following the previous version’s compilation instructions provided this nasty message:

[ 4%] Building CXX object gstreamer/CMakeFiles/phonon_gstreamer.dir/audiooutput.cpp.o
In file included from /sources/phonon-backend-gstreamer-4.5.1/gstreamer/audiooutput.cpp:22:0:
/sources/phonon-backend-gstreamer-4.5.1/gstreamer/mediaobject.h:200:38: error: ‘NavigationMenu’ is not a member of ‘Phonon::MediaController’
/sources/phonon-backend-gstreamer-4.5.1/gstreamer/mediaobject.h:200:38: error: ‘NavigationMenu’ is not a member of ‘Phonon::MediaController’
/sources/phonon-backend-gstreamer-4.5.1/gstreamer/mediaobject.h:200:69: error: template argument 1 is invalid/sources/phonon-backend-gstreamer-4.5.1/gstreamer/mediaobject.h:262:11: error: ‘NavigationMenu’ is not a member of ‘Phonon::MediaController’
/sources/phonon-backend-gstreamer-4.5.1/gstreamer/mediaobject.h:262:11: error: ‘NavigationMenu’ is not a member of ‘Phonon::MediaController’/sources/phonon-backend-gstreamer-4.5.1/gstreamer/mediaobject.h:262:42: error: template argument 1 is invalid
/sources/phonon-backend-gstreamer-4.5.1/gstreamer/mediaobject.h:263:45: error: ‘Phonon::MediaController::NavigationMenu’ has not been declared
/sources/phonon-backend-gstreamer-4.5.1/gstreamer/mediaobject.h:317:11: error: ‘NavigationMenu’ is not a member of ‘Phonon::MediaController’
/sources/phonon-backend-gstreamer-4.5.1/gstreamer/mediaobject.h:317:11: error: ‘NavigationMenu’ is not a member of ‘Phonon::MediaController’/sources/phonon-backend-gstreamer-4.5.1/gstreamer/mediaobject.h:317:42: error: template argument 1 is invalid
make[2]: *** [gstreamer/CMakeFiles/phonon_gstreamer.dir/audiooutput.cpp.o] Error 1make[1]: *** [gstreamer/CMakeFiles/phonon_gstreamer.dir/all] Error 2make: *** [all] Error 2

To fix this issue, make sure you have the latest GStreamer and phonon-backend-xine installed. Then I followed some of the advice from this KDE forum topic.

If, like me, you installed Qt into /opt/qt, create a symbolic link into the qt directory pointing to your system’s latest version of phonon. For later success with kde-runtime, create links to the libphonon libraries in /opt/qt-4.7.1/lib to your recently compiled /usr/lib64 versions (adjust paths to /usr/lib on 32-bit systems):

# mv /opt/qt-4.7.1/include/phonon /tmp
# ln -snf /usr/include/phonon /opt/qt-4.7.1/include/phonon
# cd /opt/qt-4.7.1/lib
# rm -rf libphonon*
# ln -snf /usr/lib64/libphonon.so libphonon.so
# ln -snf /usr/lib64/libphonon.so.4 libphonon.so.4
# ln -snf /usr/lib64/libphonon.so.4.5.1 libphonon.so.4.5.1
# ln -snf /usr/lib64/libphononexperimental.so libphononexperimental.so
# ln -snf /usr/lib64/libphononexperimental.so.4 libphononexperimental.so.4
# ln -snf /usr/lib64/libphononexperimental.so.4.5.1 libphononexperimental.so.4.5.1

Then rerun the compilation process for phonon-backend-gstreamer and voila, no more errors. (You’ll probably still have more issues to work out, but this gets past the phonon-backend-gstreamer blockade.)

I’ve now been actively using my (Beyond) Linux from Scratch installation for about a week now, and it’s actually pretty neat to have something working that I built with just a general outline. Granted, the LFS guide is very well put together, but going beyond the basic console of a system requires a bit of time and effort.

In really any other distro, the package manager should really be your best friend (except when it breaks.) Even in a source-based Linux like Gentoo, Portage gives you a pretty decent idea of what’s installed and is able to keep track of dependencies. With LFS, there are really some times where I don’t want to have to locate and download seventeen .tar.bz2 files, and ./configure –prefix=/usr; make; make install to each one in sequence. What’s worse is when you run into three dependencies for a particular piece of software, and the first two install properly, but the third one depends on ten additional packages.

This is what building software in LFS looks like.

There are also some libraries that despite being built on an x86_64 system will come out as 32-bit, and require special compiler or configure flags in order to build a pure 64-bit version. LFS x86_64 does not really have patience for anything 32-bit. This is generally fine because you’re building most of the applications yourself, but you can’t “just run” any typical application unless it’s taken the architecture into account.

In summary, while it’s awesome to go to SourceForge and have the very latest version of a package, sometimes I just don’t feel like going through all those hoops and satisfying twenty conditions for a compile to take place. Perhaps I’m OK if your application uses a built-in library rather than relying on whatever happens to be installed in /usr/lib.

The takeaway from this is that besides providing the source, considerate developers should try and build an i686 and x86_64 binary from that same source. If your build system has issues or you find it painful to produce binary releases, remember that anyone attempting to follow the INSTALL file will run into the same pain points. Firefox, for example, has both i686 and x86_64 release tarchives. The 64-bit version works quite well on my LFS installation and it’s how I’m writing this post.

Using the instructions from the BLFS book with the latest available 3.6 build of Firefox, I was able to achieve success. I figured I’d try out 3.6 before going onto something with a terribly inflated version number, and as per usual, ran into some problems:

• Rebuild libpng-1.5.5 with APNG support. This is actually optional as I ended up commenting out the –with-system-png option in mozconfig.
• In the suggested mozconfig, comment out the last two lines:
  

  #ac_add_options --with-system-libxul
  #ac_add_options --with-libxul-sdk=/usr/lib/xulrunner-devel-1.9.2.13

  to create a standalone build.

• Apply the GCC patch from this Bugzilla report (direct download).
• Apply a partial patch from the Chromium project of all places. I’ve customized it here:
  

  
  # TLE Patch for Firefox/LFS

  diff -u a/gfx/ots/src/os2.cc b/gfs/ots/src/os2.cc
  — a/gfx/ots/src/os2.cc 2011-11-02 07:10:17.000000000 -0400
  +++ b/gfx/ots/src/os2.cc 2011-11-02 07:10:30.000000000 -0400
  @@ -5,6 +5,7 @@
  #include “os2.h”

  #include “head.h”
  +#include <cstddef>

  // OS/2 – OS/2 and Windows Metrics
  // http://www.microsoft.com/opentype/otspec/os2.htm

• Apply a GCC4.6-specific patch to fix various .cpp files. Some parts of the patch will fail; that’s expected.
• Manually edit layout/style/nsCSSRuleProcessor.cpp and go to line 1199. Change the source code as follows:
  
  const nsCaseInsensitiveStringComparator ciComparator;
  should become
  
  const nsCaseInsensitiveStringComparator ciComparator = nsCaseInsensitiveStringComparator();
  
• For the toolkit/components/places/src/SQLFunctions.cpp file, change line 126 to:
  const nsCaseInsensitiveStringComparator caseInsensitiveCompare = nsCaseInsensitiveStringComparator();
• In toolkit/crashreporter/google-breakpad/src/common/linux/language.cc, make sure line 51 is changed to:
  const CPPLanguage CPPLanguageSingleton = CPPLanguage();
• In toolkit/xre/nsAppRunner.cpp, line 990:
  
  static const nsXULAppInfo kAppInfo = nsXULAppInfo();
  
• While this is resolved in newer Firefox versions, copy security/coreconf/Linux2.6.mk to security/coreconf/Linux3.1.mk to add support for the 3.1 kernel.

Your reward will be a working Firefox installation:

So I wanted to install XMMS in Linux From Scratch, as it’s one of the more reliable MP3 players and one of the first multimedia Linux apps I’ve used. It’s very reminiscent of Winamp 2:

If you would also like to get it installed, you’ll need the source and glib-1.2.10. Then, check out a common problem when installing glib, and a patch to fix the ./configure step.

kdebindings

Are you running into the following problem when compiling kdebindings? Well, you’re probably not, because you picked a saner distribution than LFS, but here goes anyway!

ASSERT failure in QList::at: “index out of range”, file /qt/trunk/include/QtCore/qlist.h, line 456
/bin/sh: line 1: 7841 Aborted (core dumped)

From http://old.nabble.com/Smokegen-core-dump-td30797484.html, you can fix this with a patch to indexedstring.cpp:

--- generator/parser/indexedstring.cpp.orig 2011-02-23 22:12:38.695255708 +0100
+++ generator/parser/indexedstring.cpp 2011-02-24 02:36:09.035361151 +0100
@@ -195,12 +195,15 @@
}

QByteArray IndexedString::byteArray() const {
+  qDebug() << "strings()->size():" << strings()->size() << ", m_index:" << m_index;
if(!m_index)
return QByteArray();
else if((m_index & 0xffff0000) == 0xffff0000)
return QString(QChar((char)m_index & 0xff)).toUtf8();
-  else
+  else if (m_index < strings()->size())
return strings()->at(m_index).toUtf8(); /*arrayFromItem(globalIndexedStringRepository->itemFromIndex(m_index));*/
+  else
+    return QByteArray();
}

unsigned int IndexedString::hashString(const char* str, unsigned short length) {

I ended up removing the first qDebug() line before the if statement as I don’t need my compiler to be that chatty – I just need this package to compile properly. Reconfigure and attempt to make with:

cmake -DCMAKE_INSTALL_PREFIX=$KDE4_PREFIX \
    -DKDE_DEFAULT_HOME=.kde4 \
    -DSYSCONF_INSTALL_DIR=/etc/kde4 \
    .. &&
make

kdebase-runtime

You can patch away your problems if you run into the following message:

[ 39%] Building CXX object kioslave/nfs/CMakeFiles/kio_nfs.dir/kio_nfs.o
In file included from /sources/kdebase-runtime-4.6.0/kioslave/nfs/kio_nfs.cpp:21:0:
/sources/kdebase-runtime-4.6.0/kioslave/nfs/kio_nfs.h:33:21: fatal error: rpc/rpc.h: No such file or directory
compilation terminated.

First, get libtirpc installed to make this work, but then again, you could have just guessed that you needed it, right?

Used under Creative Commons NC license from zhenech

There are some LFS-specific instructions to follow before libtirpc will compile:

• Unpack glibc-2.14.1
• In its directory, execute:

  mkdir -p /usr/include/rpc{,svc}
  cp sunrpc/rpc/*.h /usr/include/rpc
  cp nis/rpcsvc/*.h /usr/include/rpcsvc

• Compile libtirpc with ./configure --prefix=/usr && make && make install

Then from Sourcemage, linking to an old Bugzilla installation:

diff --git a/kioslave/nfs/CMakeLists.txt b/kioslave/nfs/CMakeLists.txt
index b973a73..6556769 100644
--- a/kioslave/nfs/CMakeLists.txt
+++ b/kioslave/nfs/CMakeLists.txt
@@ -3,8 +3,8 @@ set(kio_nfs_PART_SRCS kio_nfs.cpp mount_xdr.c nfs_prot_xdr.c )

 kde4_add_plugin(kio_nfs ${kio_nfs_PART_SRCS})

-
-target_link_libraries(kio_nfs   ${KDE4_KIO_LIBS})
+include_directories(/usr/include/tirpc)
+target_link_libraries(kio_nfs   ${KDE4_KIO_LIBS} tirpc)

 install(TARGETS kio_nfs  DESTINATION ${PLUGIN_INSTALL_DIR} )

Once this is complete you should be able to get kdebase-runtime compiled.

Fixing libmng with -fPIC

In preparation for getting KDE4 (and Qt4, and all the other dependencies) working with my Linux from Scratch install, I noticed an issue when compiling libmng:

/usr/bin/ld: libmng_chunk_io.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
libmng_chunk_io.o: could not read symbols: Bad valuecollect2: ld returned 1 exit status
make: *** [libmng.so.1.1.0.9] Error 1

To fix this, you’ll have to edit the makefile in /sources/libmng-1.0.10/makefiles/makefile.linux as per this osdir mailing list thread. Line 47 currently reads:

FLAGS=-I$(ZLIBINC) -I$(JPEGINC) -I$(LCMSINC) -Wall -O3 -funroll-loops \

Add the -fPIC flag instead:

FLAGS=-I$(ZLIBINC) -I$(JPEGINC) -I$(LCMSINC) -Wall -O3 -fPIC -funroll-loops \

Then change back to /sources/libmng-1.0.10 and run make clean; cp makefiles/makefile.linux Makefile && make to successfully compile the library.

And Xine

Xine appears to be missing a header, causing an xmcc compilation error. Check out the original solution and add the line with the + where indicated:

Index: src/video_out/xxmc.h
src/video_out/xxmc.h 2011-01-23 17:55:01.333928003 +0100
+++ src/video_out/xxmc.h 2011-01-23 17:54:48.509926463 +0100
@@ -79,6 +79,7 @@
#include <X11/extensions/Xvlib.h>
#ifdef HAVE_VLDXVMC
#include <X11/extensions/vldXvMC.h>
+ #include <X11/extensions/XvMClib.h>
#else
#include <X11/extensions/XvMClib.h>
#include <X11/extensions/XvMC.h>

If you’re going through the Beyond Linux From Scratch guide, and run into this error while compiling qca-2.0.3 (and I assume many other versions of qca), I think I can help.

You don’t seem to have ‘make’ or ‘gmake’ in your PATH.
Cannot proceed.

The fix is relatively easy. Just make sure to have which installed on the machine. Jake found this out the hard way by looking through the configure script. Doing this experiment on Linux From Scratch has really given me an appreciation for distributions that come with basic utilities such as which.

Since which is very difficult to find on Google, here is a link: http://www.linuxfromscratch.org/blfs/view/svn/general/which.html