On 09/07/13 09:57, O. Hartmann wrote:
On Sat, 07 Sep 2013 09:42:05 +0200
Guido Falsi <madpi...@freebsd.org> wrote:
On 09/07/13 08:10, O. Hartmann wrote:
On Sat, 07 Sep 2013 02:10:50 +0400
Boris Samorodov <b...@passap.ru> wrote:
07.09.2013 01:51, O. Hartmann пишет:
On Fri, 06 Sep 2013 21:11:26 +0400
Boris Samorodov <b...@passap.ru> wrote:
06.09.2013 20:44, O. Hartmann пишет:
On Fri, 06 Sep 2013 20:08:59 +0400
Boris Samorodov <b...@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 <madpi...@freebsd.org>
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
