In order to distcc on our 16 core Debian servers, I have my CHOST set to theirs, because otherwise everything goes to hell. I don’t know much about the CHOST variable, but it seems to be rather loosely defined. And only enforced by convention. So… I should be able to change it, right?

basalt zlib-1.2.5.1-r2 # grep CHOST /etc/make.conf
# WARNING: Changing your CHOST is not something that should be done lightly.
#CHOST="x86_64-pc-linux-gnu"
CHOST="x86_64-linux-gnu"

So I removed the “pc”, b/c who really cares. I’m sure that warning can be safely ignored. It’s still Linux and it’s still a 64-bit build. It turns out that no one does care, except for a little unknown, unused piece of software named “libz”. libz is like dependency number 1 for every piece of software on the system. It’s so old^H^H^H foundational, that its source directory contains Makefiles for msdos, as400, and amiga. Yikes.

When one tries to emerge libz, badness ensues. Everything builds OK, but actually when it goes to install, it builds up with error message that I cannot interpret. Something like:

 * ERROR: sys-libs/zlib-1.2.5-r2 failed (install phase):
 *   unable to read SONAME from libz.so 

I don’t know exactly what SONAME is, but apparently some symbol that needs to be there. I guess I could read the wikipedia article if I needed to know more. If you do a:

objdump -x libz.so | grep SONAME 

it should show: soname libz.so.1

So, the trick is that libz’s configure script determines the uname from a crappy regular expression of the CHOST variable. And the gentoo dev’s know about this, but don’t really care. See the penultimate comment here. “Do I understand correctly that if you used the canonical CHOST, then no problem arises, and therefore there is nothing for the Gentoo developers to fix? Could you explain why you want a custom CHOST?” There are reasons, I assure you.

Anyways, the problem can be worked around in the rare events that libz needs to be upgraded. You just have to step through the ebuild process and hack the configure script.

# ebuild /usr/portage/sys-libs/zlib/zlib-1.2.5.1-r2.ebuild prepare

Go into /var/tmp/portage/sys-libs/zlib-1.2.5.1-r2/work/zlib-1.2.5.1 and edit the configure script. Change this line:

if [ -n "${CHOST}" ]; then
    uname="`echo "${CHOST}" | sed -e 's/^[^-]*-\([^-]*\)$/\1/' -e 's/^[^-]*-[^-]*-\([^-]*\)$/\1/' -e 's/^[^-]*-[^-]*-\([^-]*\)-.*$/\1/'`"

to:

if [ -n "${CHOST}" ]; then
    uname=Linux

The proceed with the rest of the ebuild:

rm /var/tmp/portage/sys-libs/zlib-1.2.5.1-r2/.setuped
# ebuild /usr/portage/sys-libs/zlib/zlib-1.2.5.1-r2.ebuild configure
# ebuild /usr/portage/sys-libs/zlib/zlib-1.2.5.1-r2.ebuild install
# ebuild /usr/portage/sys-libs/zlib/zlib-1.2.5.1-r2.ebuild qmerge

Should be all good.



blog comments powered by Disqus

Published

23 May 2012

Category

work

Tags