Linux/Unix/BSD

If you get the following error message when trying to compile some software application on Ubuntu (or Kubuntu or Xubuntu or similar) then you need to install the “build-essential” packages.

C++ compiler cannot create executables

This is simply a matter of opening up a command line prompt (but then you were already there if you were trying to compile something) and issue the following command:

sudo apt-get install build-essential

You’ll get some output like this, after which you should be able to continue trying to compile your software package:

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  dpkg-dev g++ g++-4.1 libstdc++6-4.1-dev patch
Suggested packages:
  debian-keyring g++-multilib g++-4.1-multilib gcc-4.1-doc libstdc++6-4.1-doc diff-doc
The following NEW packages will be installed:
  build-essential dpkg-dev g++ g++-4.1 libstdc++6-4.1-dev patch
0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/3995kB of archives.
After unpacking 14.6MB of additional disk space will be used.
Do you want to continue [Y/n]? Y
Selecting previously deselected package libstdc++6-4.1-dev.
(Reading database ... 86000 files and directories currently installed.)
Unpacking libstdc++6-4.1-dev (from .../libstdc++6-4.1-dev_4.1.2-16ubuntu2_i386.deb) ...
Selecting previously deselected package g++-4.1.
Unpacking g++-4.1 (from .../g++-4.1_4.1.2-16ubuntu2_i386.deb) ...
Selecting previously deselected package g++.
Unpacking g++ (from .../g++_4.1.2-9ubuntu2_i386.deb) ...
Selecting previously deselected package patch.
Unpacking patch (from .../p/patch/patch_2.5.9-4_i386.deb) ...
Selecting previously deselected package dpkg-dev.
Unpacking dpkg-dev (from .../dpkg-dev_1.14.5ubuntu16_all.deb) ...
Selecting previously deselected package build-essential.
Unpacking build-essential (from .../build-essential_11.3ubuntu1_i386.deb) ...
Setting up patch (2.5.9-4) ...
Setting up dpkg-dev (1.14.5ubuntu16) ...
Setting up libstdc++6-4.1-dev (4.1.2-16ubuntu2) ...
Setting up g++-4.1 (4.1.2-16ubuntu2) ...
Setting up g++ (4:4.1.2-9ubuntu2) ...

Setting up build-essential (11.3ubuntu1) ...

I have been running openSUSE on my primary desktop machine since December last year, and upgraded recently from openSUSE 10.2 to openSUSE 10.3. The Yast control center is a good piece of software, but the software management part of it seems to get slower and slower with each new release so I have been looking at using Yum instead.

After installing some software using Yum this morning, which was much faster than using the Yast software installer, I went to install something else this evening and got the following error message when I clicked on the “Software Management” icon in Yast:

Error loading language plugin /usr/lib64/YaST2/plugin/libpy2lang_perl.so: libboost_filesystem.so.1.33.1: cannot open shared object file: No such file or directory
 No such client module sw_single

That was an odd sort of message. I had installed something to do with Yast this morning, so perhaps yum had managed to break it. I’m fairly sick of SUSE’s package management so nothing really surprises me when things go wrong with it these days.

I checked, and the libboost_filesystem.so.1.33.1 file was present on the file system. However, doing an ldd on ldd /usr/lib64/YaST2/plugin/libpy2lang_perl.so showed up some interesting information. ldd is a tool which lets you work out which library dependencies there are for an executable file.

ldd /usr/lib64/YaST2/plugin/libpy2lang_perl.so
 ...
 librpm-4.4.so => not found
 ...
 

ldd was telling me that librpm-4.4.so did not exist. I did a quick locate librpm-4.4.so to find out where the file was, and then ls -l /usr/lib/librpm-4.4.so to confirm the file really was there. And of course it was, so something was really messed up.

I popped the installation DVD into the drive and located the rpm file by doing this:

find /media/dvd. -name "rpm*"

This returned:

/media/dvd/x86_64/rpm-4.4.2-140.x86_64.rpm
 /media/dvd/x86_64/rpm-devel-4.4.2-140.x86_64.rpm
 /media/dvd/x86_64/rpm-python-4.4.2-164.x86_64.rpm

So I installed the pm-4.4.2-140.x86_64.rpm RPM file like so, using the –ignorearch and –force flags because I’d been having some issues installing other files while I was trying to work out the problem:

rpm --ignorearch --force -ivh ./x86_64/rpm-4.4.2-140.x86_64.rpm

An ldd on /usr/lib64/YaST2/plugin/libpy2lang_perl.so now revealed

ldd /usr/lib64/YaST2/plugin/libpy2lang_perl.so
 ...
 libboost_filesystem.so.1.33.1 => not found
 ...
 

So another quick search and install…

$ find /media/dvd -name "boost*"
 /media/dvd/x86_64/boost-1.33.1-108.x86_64.rpm
 /media/dvd/x86_64/boost-devel-1.33.1-108.x86_64.rpm
 /media/dvd/x86_64/boost-doc-1.33.1-108.x86_64.rpm
 /media/dvd/x86_64/boost-jam-3.1.14-14.x86_64.rpm
 $ rpm -ivh /media/dvd/x86_64/boost-1.33.1-108.x86_64.rpm

ldd now showed all the dependencies were available (never mind that they were there all along), and I could now run the software management function from yast without any further issues.

Update November 24th 2007: I have posted instructions for installing Yum on SUSE and some screenshots of the KYum graphical frontend for Yum, having successfully run Yum for a few weeks now.

If you do a lot of command line stuff in Linux, sooner or later you’ll come across the "argument list too long" error when copying, moving, deleting, listing etc files in a directory that contains a lot of files. This post looks at a couple of ways of solving this problem.

A long running process running on a Unix/Linux command line may stop running if you lose your SSH session. Using the "nohup" command will allow the command to keep running if you lose your connection or need to logout. This post looks at how to do this.

Often when shell scripting with BASH you need to test if a file exists (or doesn’t exist) and take appropriate action. This post looks at how to check if a file exists with the BASH shell.