On 09/07/13 09:57, O. Hartmann wrote: > 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. Sure, I understand that. > > I can still see most of the listed ports also in the list of the "to > do" for being recompiled. Yes, that's expected. One or more of these are being put in the wrong order by portmaster though, for some reason. Try to start portmaster against these, which are anyway much less that the whole list life for portmaster should be easier. > > accessibility/at-spi2-atk > accessibility/at-spi2-core > converters/psiconv > devel/glade3 > textproc/gnome-spell > 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 I'm just guessing but this stripped down list contains the most probable offenders. > mail/claws-mail-fancy > mail/claws-mail-notification > mail/claws-mail-pdf_viewer > mail/claws-mail-vcalendar I don't know claws-mail, but I see it has various modules. It may be necessary to rebuild the while package with "portmaster claws" since it is possible some module(or the base software) isn't being rebuild but needs to anyway. -- Guido Falsi <madpilot_at_FreeBSD.org>Received on Sat Sep 07 2013 - 06:11:35 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:41 UTC