Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv

From: Guido Falsi <madpilot_at_FreeBSD.org>
Date: Sat, 07 Sep 2013 09:42:05 +0200
On 09/07/13 08:10, O. Hartmann wrote:
> On Sat, 07 Sep 2013 02:10:50 +0400
> Boris Samorodov <bsam_at_passap.ru> wrote:
>
>> 07.09.2013 01:51, O. Hartmann пишет:
>>> On Fri, 06 Sep 2013 21:11:26 +0400
>>> Boris Samorodov <bsam_at_passap.ru> wrote:
>>>
>>>> 06.09.2013 20:44, O. Hartmann пишет:
>>>>> On Fri, 06 Sep 2013 20:08:59 +0400
>>>>> Boris Samorodov <bsam_at_passap.ru> wrote:
>>>>>
>>>>>> 06.09.2013 19:44, O. Hartmann пишет:
>>>>>>
>>>>>>> Here we go. It is the config.log from one of the failing
>>>>>>> machines, failing in print/cups-client.
>>>>>>
>>>>>> Please, show the output of following commands (at the host in
>>>>>> question): # svn info /usr/ports/
>>>>>> # svn svn st /usr/ports/print/cups*
>>>>>>
>>>>> svn info /usr/ports/
>>>>>
>>>>> Path: /usr/ports
>>>>> Working Copy Root Path: /usr/ports
>>>>> URL: svn://svn.de.freebsd.org/ports/head
>>>>> Relative URL: ^/head
>>>>> Repository Root: svn://svn.de.freebsd.org/ports
>>>>> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
>>>>> Revision: 326523
>>>>> Node Kind: directory
>>>>> Schedule: normal
>>>>> Last Changed Author: danfe
>>>>> Last Changed Rev: 326523
>>>>> Last Changed Date: 2013-09-06 18:22:29 +0200 (Fri, 06 Sep 2013)
>>>>>
>>>>>
>>>>> svn st /usr/ports/print/cups*
>>>>> ?       /usr/ports/print/cups-base/work
>>>>> ?       /usr/ports/print/cups-client/work
>>>>
>>>> That is really stange... Some more info:
>>>> # svn st /usr/ports/Mk
>>>
>>> nothin (NULL output)
>>>
>>>> # make -C /usr/ports/print/cups-client -V ICONV_LIB -V
>>>> CONFIGURE_ARGS
>>>>
>>> make -C /usr/ports/print/cups-client -V ICONV_LIB -V CONFIGURE_ARGS
>>>
>>> --localstatedir=/var
>>> --disable-slp
>>> --disable-gssapi                        --with-cups-user=cups
>>> --with-cups-group=cups           --with-system-groups=wheel
>>> --with-docdir=/usr/local/share/doc/cups
>>> --with-icondir=/usr/local/share/icons
>>> --with-menudir=/usr/local/share/applications
>>> --with-domainsocket=/var/run/cups.sock  --with-cachedir=/var/db/cups
>>> --with-pam-module="unix"                --enable-ssl
>>> --with-printcap=/usr/local/etc/printcap --disable-gnutls
>>> --enable-openssl --without-php --disable-dnssd --disable-pam
>>> --disable-ldap --disable-dbus --disable-libusb
>>> LIBS="-lssp_nonshared" --prefix=/usr/local ${_LATE_CONFIGURE_ARGS}
>>
>> Well, the output is perfect.
>>
>>> I see a lot of those obscure libtool errors not finding libiconv.la.
>>> Where the hell does the tool take those ecos from the past? I guess
>>> I have to reboot the box after X11 has been compiled
>>
>> Did not see those. Since so far it seems that such errors are not
>> common, may be something at your environment causes this (may be
>> at /etc/make.conf)?
>>
>
> This morning after a boot of two machines in question, I see those here
> for building mail/claws-mail-fancy, which fails, by the way (gmake,
> flex, autotools, gawk et cetera has been rebuild very early in the build
> process as well as several other baseline ports, like coreutils).
>
> I tried to track down the libraries included when linking, but it seems
> that those has already been rebuild already.
>
> [...]
> /bin/sh ../../../libtool --tag=CC   --mode=link cc  -O2 -pipe -O3
[...]
> -lcrypto -lgssapi -lz -lexpat -lssl -lcrypto -lsasl2
> grep: /usr/local/lib/libiconv.la: No such file or directory
> sed: /usr/local/lib/libiconv.la: No such file or directory libtool:
> link: `/usr/local/lib/libiconv.la' is not a valid libtool archive
>

Lets try to find what is still blocking libtool, can you try performing:

find /usr/local/lib -name '*.la' -exec grep -qi iconv {} \; -print | 
xargs -n 1 pkg which -oq | sort -u

this convoluted one liner should give a list of ports still having 
libtool files with iconv hardwired in them in /usr/local/lib. You
u should rebuild them. Usually portmaster and portupgrade are able to 
guess the right order, so you can also add  "| xargs portmaster" or "| 
xargs portupgrade -f" to it to simply start the update.

The grep for iconv may be a little overkill, most probably grep 
libiconv" is enough, but they should detect the same things anyway.

-- 
Guido Falsi <madpilot_at_FreeBSD.org>
Received on Sat Sep 07 2013 - 05:42:10 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:41 UTC