Using Gentoo on a server without C++ compiler

| 1 Comment | No TrackBacks

After reading a post by Diego E. Pettenò about replacing groff with heirloom-doctools leading to having nearly no C++ programs in a Gentoo system, I tried to rebuild all packages on my Gentoo-using server without C++. The main difference is that my computer compiles all packages instead of using another system for this, so I need also all build dependencies of useful packages compiling and working without C++.

I started by adding the nocxx -cxx USE flags to everything except GCC. Rebuilding affected packages showed that app-arch/lzma-utils has programs written in C++ for everything except decompression. So I checked on my unstable Gentoo workstation that its app-arch/xz-utils does not have programs linking to libstdc++, which is nearly equivalent to using C++. Therefore I added app-arch/xz-utils to /etc/portage/package.keywords and installed it. Now both LZMA and XZ compression formats may be both compressed and decompressed, without any C++ code.

Since C++ support is assumed to be in every system, the package manager cannot determine which packages use it. Therefore I decided to check which programs link to the C++ standard library. The following shell script lists all files on $PATH which link to libraries containing ++ in their names:

#!/bin/sh

for directory in `echo $PATH | sed 's/:/ /g'`;
do
  for f in $directory/*
  do
    if file $f | grep ELF > /dev/null
    then
      list=`readelf -dw $f | grep Shared \
        | sed -r 's/^.*\[(.*)\].*$/\1/' | fgrep ++`
      if [ $? = 0 ]
      then
        echo $f
      fi
    fi
  done
done

Passing the output of the script to xargs qfile -q | sort -u listed packages having these files.

The only necessary packages on my system listed by the above pipe were app-arch/lzma-utils and sys-apps/groff, but they can be easily replaced by app-arch/xz-utils and app-doc/heirloom-doctools.

Then I compiled sys-devel/gcc with the nocxx USE flag and ran emerge -ev --keep-going world.

Next day I saw that build failed for 27 packages. Some of them, like sys-apps/sed had just failing tests for completely unrelated reasons. Many other packages, like sys-devel/libtool have tests using C++. So I recompiled all such packages with FEATURES=-test. Now only 12 packages failed.

The rest failed mostly when running the configure script, with messages like this:

checking how to run the C++ preprocessor... /lib/cpp
configure: error: C++ preprocessor "/lib/cpp" fails sanity check

These were caused by useless checks for C++ compiler made by older versions of libtool. In case of dev-libs/popt and sys-apps/shadow updating to the testing version solved this, but for some other packages adding eautoreconf to their ebuilds was necessary.

After these changes the only packages with build errors were dev-libs/apr, net-libs/courier-authlib and net-mail/courier-imap. The first one also fails at the configure check, while the rest uses some C++ code which is not installed.

The modified ebuilds were available in my overlay. I haven’t reported any of the problems observed to the Gentoo Bugzilla, since I cannot access it today and the changes would just make compilation slower in all normal uses.

No TrackBacks

TrackBack URL: http://blog.mtjm.eu/cgi-bin/mt/mt-tb.cgi/12

1 Comment

Glad that I'm not the only one wanting C++ out of his server ;)

Just a few notes: the script can be _quite_ simplified :)

scanelf -N libstdc++.so.6 -Rplq

This will list all the files, in both the execution path and the library path, linking to libstdc++.so.6 (the C++ standard library indeed).

Second, regarding C++-based tests, that's something a bit borderline on whether it's accepted or not; sincerely, I'd be putting them under conditional, so if you want to mail me which packages failed, I'll be glad to take a look at what I can do.

And finally, the software that fails to pass ./configure without C++ does not really need full-blown eautoreconf, it should be quite enough to call the epunt_cxx function from libtool.eclass, which is designed to fix just that problem. Those you can report to bugzilla quite safely, but CC me on those bugs or they might be handled badly (we're a handful of devs to know about epunt_cxx I'm afraid).

Looking forward to see your results!