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

On Sat, 07 Sep 2013 09:42:05 +0200
Guido Falsi <madpilot_at_FreeBSD.org> wrote:

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

Below the requested list. But the system is "at work" again, means, I
proceed the update after having had a rest at night.

I can still see most of the listed ports also in the list of the "to
do" for being recompiled.

accessibility/at-spi2-atk
accessibility/at-spi2-core
converters/psiconv
databases/libgda4
devel/devhelp
devel/eggdbus
devel/glade3
devel/libgdata
devel/libzvbi
editors/abiword
graphics/colord
graphics/gdal
graphics/gegl
graphics/gimp-app
mail/claws-mail-fancy
mail/claws-mail-notification
mail/claws-mail-pdf_viewer
mail/claws-mail-vcalendar
multimedia/libxine
multimedia/py-gstreamer
multimedia/vcdimager
multimedia/vlc
net/libcmis
print/gutenprint-base
security/cracklib
security/seahorse
textproc/gnome-spell
textproc/libvisio
textproc/rasqal
textproc/redland
x11-toolkits/gtk30
x11-toolkits/gtkglext
x11-toolkits/gtkmm24
x11-toolkits/pangox-compat
x11-toolkits/py-gtk2
x11-toolkits/py-gtksourceview
x11-toolkits/py-vte
x11-toolkits/unique
x11/gnome-desktop