sys-libs/zlib-1.1.4-r1 gets installed correctly without distcc. Using distcc the files /usr/lib/zlib.so* are missing.
Are you sure you're not looking for /usr/lib/libz.so* ? (Note the position of the 'z')
He is looking for /usr/lib/libz.so*. When using FEATURES="distcc" these files are not build. It builds fine without "distcc".
From `qpkg -l zlib' on a box that compiled zlib with distcc. This matches two other boxen that both used distcc. My tests locally confirmed that even without using distcc or ccache (removed from FEATURES and ${PATH}) there are no /usr/lib/zlib.so* files. sys-libs/zlib-1.1.4-r1 * CONTENTS: /usr /usr/include /usr/include/zconf.h /usr/include/zlib.h /usr/lib /usr/lib/libz.so.1.1.4 /usr/lib/libz.a /usr/lib/libz.so -> libz.so.1.1.4 /usr/lib/libz.so.1 -> libz.so.1.1.4 /usr/share /usr/share/man /usr/share/man/man3 /usr/share/man/man3/zlib.3.gz /usr/share/doc /usr/share/doc/zlib-1.1.4-r1 /usr/share/doc/zlib-1.1.4-r1/txt /usr/share/doc/zlib-1.1.4-r1/txt/algorithm.txt.gz /usr/share/doc/zlib-1.1.4-r1/FAQ.gz /usr/share/doc/zlib-1.1.4-r1/README.gz /usr/share/doc/zlib-1.1.4-r1/ChangeLog.gz
I'm going to reopen this. I had the exact same thing happen to me before. And I just noted a few users in the forums who have seen this as well. The problem is that in some cases, I believe, the configure test gets sent off to the remote machine and the results don't get sent back positive in time for the script to denote that shared library support is available. Note that you can manually call the configure script in the workdir, and all is well in the world. This is haphazard, as some machines it will work okay on, and some it doesn't. But, since it's non-deterministic, I don't know a workaround, other than not compiling zlib with distcc. Thoughts?
I would suggest doing what Mozilla and Xfree does - forcing MAKEOPTS="${MAKEOPTS} -j1" and see if it works.
Confirmed - the ebuild should probably be changed to force -j1
No. I don't think MAKEOPTS="${MAKEOPTS} -j1" will solve the problem. I tried here and it still don't work. I think the problem is that the check for shared library support in the configure script is distributed. With -j1 it will still be distributed unless localhost is the first distcc host.
I tried FEATURES="${FEATURES} -distcc" but it didn't help. However, setting FEATURES="" in the ebuild did made it compile with shared library. Is there any reason that FEATURES="" shouldn't be used in the ebuild?
ugh, you're right. after checking it on another computer with -j1 it did fail. FEATURES="" is a fairly bad hack. I'm wondering if we shouldn't somehow come up with a way to not distribute the shared lib check. I guess it will need a little looking in to.
What about adding a DISTCC_HOSTS="localhost" in the ebuild? If distcc is in features it will only use localhost for this ebuild.
Only turning off distcc in /etc/make.conf did the trick for me. So I added the following to the ebuild, to just remove distcc from the features (this is more subtle than FEATURES="", but we get an extra dependency): FEATURES=`echo ${FEATURES}|sed -e "s/distcc//g"` Also modified the DEPEND line to read: DEPEND="virtual/glibc sys-apps/sed" Anyway, slightly nicer than FEATURES="", but still a hack. Might be an acceptable temporary fix, but what is really needed is for portage to provide a mechanism to turn off a particular feature in an ebuild. The previously suggested FEATURES="${FEATURES} -distcc" seems like a good candidate. Can this be made to work?
in the ebuild on each ./configure line change it to: DISTCC_HOSTS='localhost' ./configure ... As a matter of fact I should bug dev-portage about doing that by default.
Yep, that would be the best way. Here's wat happened when I used distcc to bootstrap my system (stage 1 20030910) : eutils flag-o-matic eutils flag-o-matic eutils flag-o-matic >>> Unpacking source... >>> Unpacking zlib-1.1.4.tar.bz2 to /var/tmp/portage/zlib-1.1.4-r2/work * Applying zlib-1.1.4-gentoo.security.patch... [ ok ] >>> Source unpacked. eutils flag-o-matic Checking for shared library support... No shared library suppport; try without defining CC and CFLAGS Building static library libz.a version 1.1.4 with gcc. Checking for unistd.h... No. Checking whether to use vsnprintf() or snprintf()... using snprintf() Checking for snprintf() in stdio.h... No. WARNING: snprintf() not found, falling back to sprintf(). zlib can build but will be open to possible buffer-overflow security vulnerabilities. See README.vsnprintf for more info. Checking for return value of sprintf()... No. WARNING: apparently sprintf() does not return a value. zlib can build but will be open to possible string-format security vulnerabilities. See README.vsnprintf for more info. Checking for errno.h... No. Checking for mmap support... No. gcc -O2 -mcpu=pentium2 -mcpu=pentium2 -funroll-loops -pipe -fPIC -DNO_ERRNO_H -c -o example.o example.c <snip> gcc -O2 -mcpu=pentium2 -mcpu=pentium2 -funroll-loops -pipe -fPIC -DNO_ERRNO_H -c -o minigzip.o minigzip.c distcc[24924] (dcc_build_somewhere) Warning: failed to distribute, running locally instead ar rc libz.a adler32.o compress.o crc32.o gzio.o uncompr.o deflate.o trees.o zutil.o inflate.o infblock.o inftrees.o infcodes.o infutil.o inffast.o gcc -O2 -mcpu=pentium2 -mcpu=pentium2 -funroll-loops -pipe -fPIC -DNO_ERRNO_H -o example example.o -L. -lz ./libz.a(gzio.o)(.text+0x1b6): In function `gz_open': : undefined reference to `errno' ./libz.a(gzio.o)(.text+0x4d2): In function `get_byte': : undefined reference to `errno' ./libz.a(gzio.o)(.text+0x908): In function `gzread': : undefined reference to `errno' collect2: ld returned 1 exit status distcc[24932] ERROR: compile on localhost failed make: *** [example] Error 1 make: *** Waiting for unfinished jobs.... !!! ERROR: sys-libs/zlib-1.1.4-r2 failed. !!! Function src_compile, Line 29, Exitcode 2 !!! (no error message) When turning distcc off, it works like a charm
i still can't reproduce this.
