On Wed, Jun 8, 2011 at 2:17 AM, Alberto Luaces <alua...@udc.es> wrote: > Alberto Luaces writes: > >> Hi Paul, >> >> Paul Hartman writes: >> >>> On Fri, May 27, 2011 at 11:26 AM, Alberto Luaces <alua...@udc.es> wrote: >>>> Hello, >>>> >>>> I have searched quite a bit for an error I'm having when emerging >>>> current zlib-1.2.5-r2. The problem is that somehow the soname is not >>>> written in the .so file, and the build process fails. I attach all the >>>> build logs in case I have some obvious misconfiguration that I should be >>>> aware of. I have not changed my CHOSTS or things like that. >>>> >>>> I recompiled the previous version and happened the same, but it seems >>>> at that time not having a soname was not forbidden by the ebuild and I >>>> got just a QA notice. >>>> >>>> If I try to compile zlib from the /var/tmp/portage... directory the >>>> library compiles fine and, in addition, the soname is included this >>>> time. I tried to trace the eclasses in order to know what was happening >>>> but I couldn't. >>> >>> Hi, >>> >>> Based on your settings I am guessing you have used distcc in the past, >>> even though you have disabled it now. >> >> You are right, well spotted! >> >>> I think zlib's configure makes some changes based on if it thinks you >>> use distcc or not. I would try to unset CC in environment and remove >>> -m32 from your CFLAGS and see if it is any different. It's only a >>> guess and you can change it back if it doesn't work. >>> >> >> My environment CC was empty or already unset, I removed the `-m32' tag >> but it happens the same. >> >>> >>> I would also select again your preferences in gcc-config and >>> binutils-config, run env-update and source /etc/profile just to be >>> sure everything is in working order. :) >>> >> >> I followed your advice. I have only another compiler, the mingw cross >> compiler, but I checked that is not selected byb default. >> >> Nevertheless, thank you for your help. You gave me the idea on focusing >> on zlib's configure script in order to see what is failing in the >> detection process. > > I finally found it. Turns out that for using distcc I had to set CC=cc > in make.conf, and with that setting, zlib's configure avoided to build > the shared library. Unsetting CC in make.conf made it working again.
Glad to hear it, I knew something about that CC looked suspicious. :)
