Re: [gentoo-user] Re: ebuild not inserting soname, therefore emerging zlib fails

[Paul Hartman <paul.hartman+gentoo@gmail.com>]

On Wed, Jun 8, 2011 at 2:17 AM, Alberto Luaces <aluaces@udc.es> wrote:
> Alberto Luaces writes:
>
>> Hi Paul,
>>
>> Paul Hartman writes:
>>
>>> On Fri, May 27, 2011 at 11:26 AM, Alberto Luaces <aluaces@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. :)