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

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

[Alberto Luaces]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

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.

Thank you,


[-- Attachment #2: zlib.logs.tar.bz2 --]
[-- Type: application/octet-stream, Size: 22467 bytes --]

[-- Attachment #3: Type: text/plain, Size: 13 bytes --]


-- 
Alberto

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

[Paul Hartman]

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. 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.

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. :)

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

[Alberto Luaces]

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.

-- 
Alberto

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

[Alberto Luaces]

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.

-- 
Alberto

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

[Paul Hartman]

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. :)