Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
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
-march=native -fno-strict-aliasing -Wno-unused-function
-Wno-pointer-sign -Wall -I/usr/local/include/enchant -pthread
-I/usr/local/include/glib-2.0 -I/usr/local/include -avoid-version
-module -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -lXext -lXrender
-lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lXfixes
-lX11 -latk-1.0 -lcairo -pthread -lgdk_pixbuf-2.0 -lgio-2.0
-lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lfreetype
-L/usr/local/lib -lfontconfig -lwebkitgtk-1.0 -lgtk-x11-2.0
-lgdk-x11-2.0 -lpangocairo-1.0 -lXext -lXrender -lXinerama -lXi
-lXrandr -lXcursor -lXcomposite -lXdamage -lXfixes -lX11 -latk-1.0
-lcairo -pthread -lgdk_pixbuf-2.0 -lpangoft2-1.0 -lpango-1.0 -lfreetype
-lfontconfig -lsoup-2.4 -lgio-2.0 -lgobject-2.0 -ljavascriptcoregtk-1.0
-L/usr/local/lib -lglib-2.0 -lintl -lsoup-gnome-2.4 -lsoup-2.4
-lgio-2.0 -lgobject-2.0 -L/usr/local/lib -lglib-2.0 -lintl
-L/usr/local/lib -lcurl -L/usr/local/lib -o fancy.la
-rpath /usr/local/lib/claws-mail/plugins fancy_viewer.lo
fancy_prefs.lo -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -lXext
-lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage
-lXfixes -lX11 -latk-1.0 -lcairo -pthread -lgdk_pixbuf-2.0 -lgio-2.0
-lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lfreetype
-L/usr/local/lib -lfontconfig -larchive -lexecinfo -lm
-L/usr/local/lib -letpan -L/usr/local/lib -pthread
-Wl,-rpath=/usr/lib:/usr/local/lib -L/usr/local/lib -lcurl -lssl
-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
Oliver
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
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.
--
Guido Falsi madpi...@freebsd.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
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.
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
Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
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
FreeBSD ports which are currently marked broken
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: accessibility/yasr broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=accessibilityportname=yasr portname: archivers/ruby-bz2 broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=ruby-bz2 portname: audio/ruby-vorbisfile broken because: does not compile with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-vorbisfile portname: audio/ruby-xmms broken because: does not compile with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-xmms portname: biology/dotter broken because: checksum mismatch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=biologyportname=dotter portname: cad/salome-geom broken because: fails to build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=salome-geom portname: cad/salome-kernel broken because: Does not configure build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=salome-kernel portname: cad/salome-med broken because: Fails to fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=salome-med portname: cad/salome-yacs broken because: fails to build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=salome-yacs portname: chinese/big5con broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=big5con portname: chinese/bitchx broken because: patch reject build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=bitchx portname: chinese/hztty broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=hztty portname: converters/p5-Unicode-Lite broken because: Overwrites bin/map from converters/p5-Unicode-Map build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=convertersportname=p5-Unicode-Lite portname: converters/pdf2djvu broken because: does not build build errors: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.10.20130313090402.pointyhat/pdf2djvu-0.5.11_10.log (Mar 14 00:22:50 UTC 2013) overview: http://portsmon.FreeBSD.org/portoverview.py?category=convertersportname=pdf2djvu portname: converters/py-svglib broken because: Does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=convertersportname=py-svglib portname: databases/drizzle broken because: fails to build build errors: none. overview:
FreeBSD unmaintained ports which are currently scheduled for deletion
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically schedule removal of ports that have been judged to have outlived their usefulness. Often, this is due to a better alternative having become available and/or the cessation of development on the existing port. In some cases, ports are marked for removal because they fail to build and install correctly from their sources, or otherwise fail in operation. The ports, and the reason and date that they have been scheduled for removal, are listed below. If no one has stepped forward before that time to propose a way to fix the problems (such as via a PR), the ports will be deleted. portname: databases/ruby-interbase description:Ruby interface to Firebird/Interbase library maintainer: po...@freebsd.org status: BROKEN deprecated because: Does not work with Ruby 1.9 expiration date:2013-05-02 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-interbase portname: devel/ppl description:The Parma Polyhedra Library maintainer: po...@freebsd.org status: BROKEN deprecated because: obsolete version; fails to build expiration date:2013-09-21 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ppl portname: devel/rubygem-zoom description:A Ruby binding to the Z39.50 Object-Orientation Model (ZOOM) maintainer: po...@freebsd.org status: BROKEN deprecated because: Does not work with Ruby 1.9 expiration date:2013-05-02 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-zoom portname: net-im/jabber-pymsn description:Python MSN-Transport for Jabber maintainer: po...@freebsd.org deprecated because: Primary MSN Messenger service terminated 30 APR 2013 expiration date:2013-10-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-importname=jabber-pymsn portname: net-im/p5-Net-MSN description:Net::MSN interface maintainer: po...@freebsd.org deprecated because: Primary MSN Messenger service terminated 30 APR 2013 expiration date:2013-10-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-importname=p5-Net-MSN portname: net-im/py-msnp description:MSN messaging in Python maintainer: po...@freebsd.org deprecated because: Primary MSN Messenger service terminated 30 APR 2013 expiration date:2013-10-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-importname=py-msnp portname: net-im/pymsn description:MSN Connection library maintainer: po...@freebsd.org deprecated because: Primary MSN Messenger service terminated 30 APR 2013 expiration date:2013-10-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-importname=pymsn portname: ports-mgmt/pkg_replace description:Utility for upgrading installed packages maintainer: po...@freebsd.org deprecated because: Abandoned upstream, does not support pkgng. Consider using ports-mgmt/portmaster, ports-mgmt/portupgrade or pkgng expiration date:2013-12-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=ports-mgmtportname=pkg_replace portname: textproc/fileshuffle description:Filter for shuffling lines in a text file into random order maintainer: po...@freebsd.org deprecated because: Does not work, use gshuf from sysutils/coreutils instead expiration date:2013-09-23 build errors: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.10.20130313090402.pointyhat/fileshuffle-0.1.log (Mar 14 02:22:34 UTC 2013) overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=fileshuffle portname: textproc/referrercop description:Filters referrer spam from Apache logs and AWStats data files maintainer: po...@freebsd.org deprecated because: distfile unfetchable expiration date:2014-01-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=referrercop portname: www/notftp description:An easy to use Web to FTP gateway written in PHP maintainer: po...@freebsd.org deprecated because: distfile unfetchable expiration date:2014-01-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=wwwportname=notftp
FreeBSD unmaintained ports which are currently marked broken
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: biology/dotter broken because: checksum mismatch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=biologyportname=dotter portname: chinese/big5con broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=big5con portname: chinese/bitchx broken because: patch reject build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=bitchx portname: chinese/hztty broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=hztty portname: converters/p5-Unicode-Lite broken because: Overwrites bin/map from converters/p5-Unicode-Map build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=convertersportname=p5-Unicode-Lite portname: databases/grass broken because: Does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=grass portname: databases/msql broken because: Broken on FreeBSD 9+ build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=msql portname: databases/ruby-interbase broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-interbase portname: deskutils/libopensync-plugin-python-devel broken because: fails to build with recent libopensync build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutilsportname=libopensync-plugin-python-devel portname: devel/libYGP broken because: Does not build with recent boost build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=libYGP portname: devel/lua50-dfui broken because: Does not build build errors: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.10.20130313090402.pointyhat/lua50-dfui-0.1.20050901.log (Mar 14 00:26:27 UTC 2013) overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=lua50-dfui portname: devel/mico broken because: fails to build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=mico portname: devel/ppl broken because: fails to build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ppl portname: devel/ros_comm broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ros_comm portname: devel/rubygem-zoom broken because: does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-zoom portname: dns/opendd broken because: segfaults upon use build errors: none. overview:
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ databases/sqlclient | 1.5.3 | 1.7.0 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt If wish to stop receiving portscout reminders, please contact portsc...@freebsd.org Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
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 # make -C /usr/ports/print/cups-client -V ICONV_LIB -V CONFIGURE_ARGS After this morning's reboot and restart of the update marathon, even print/cups builds fine for now! I have no clue what went wrong. I guess most evidences and traces are gone with the restart of the boxes in question (they had all (3) the same symptoms). Thanks for looking into this, Oliver ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
On 09/07/13 12:23, O. Hartmann wrote: 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 # make -C /usr/ports/print/cups-client -V ICONV_LIB -V CONFIGURE_ARGS After this morning's reboot and restart of the update marathon, even print/cups builds fine for now! I have no clue what went wrong. I guess most evidences and traces are gone with the restart of the boxes in question (they had all (3) the same symptoms). Thanks for looking into this, Thanks to you for your patience, really! -- Guido Falsi madpi...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
On Sat, 07 Sep 2013 00:16:16 +0200
Guido Falsi madpi...@freebsd.org wrote:
On 09/07/13 00:10, Boris Samorodov 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)?
I did see some of those. libtool takes those settings from
/usr/local/lib/*.la files, installed by ports, before this change.
Many of those files hardcode -liconv.
Usually portmaster/portupgrade are good enough at guessing the
correct order, but sometimes they mess it up, and this kind of
situation happens.
On my desktop PC I had to resort to ls -lt /usr/local/lib/*.la and
portmaster the older ones. This can be further narrowed down by
grepping for -liconv.
Founf another one that is failing:
port multimedia/mlt:
3 warnings generated.
cc -shared -o ../libmltgtk2.so factory.o consumer_gtk2.o
producer_pixbuf.o pixops.o filter_rescale.o producer_pango.o
producer_count.o filter_dynamictext.o -Wl,--no-undefined
-Wl,--as-needed -Wl,--no-undefined -Wl,--as-needed -L../../framework
-lmlt -pthread -lm -Wl,--no-undefined -Wl,--as-needed `pkg-config
--libs gtk+-2.0` `pkg-config --libs gdk-pixbuf-2.0` -L/usr/local/lib
-lexif `pkg-config --libs pangoft2` -liconv
---
/usr/bin/ld: cannot find -liconv cc: error: linker command failed with
exit code 1 (use -v to see invocation) gmake[4]: *** [../libmltgtk2.so]
Error 1 gmake[4]: Leaving directory
---
`/usr/ports/multimedia/mlt/work/mlt-0.9.0/src/modules/gtk2' gmake[3]:
*** [all] Error 1 gmake[3]: Leaving directory
`/usr/ports/multimedia/mlt/work/mlt-0.9.0/src/modules' gmake[2]: ***
[all] Error 1 gmake[2]: Leaving directory
`/usr/ports/multimedia/mlt/work/mlt-0.9.0' === Compilation failed
unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before
reporting the failure to the maintainer. *** Error code 1
Stop.
make[1]: stopped in /usr/ports/multimedia/mlt
*** Error code 1
Stop.
make: stopped in /usr/ports/multimedia/mlt
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
On Sat, 7 Sep 2013 00:07:29 +0200
Baptiste Daroussin b...@freebsd.org wrote:
On Fri, Sep 06, 2013 at 11:51:32PM +0200, O. Hartmann wrote:
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}
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
Can you try to force rebuilding gettext first?
and then retry?
regards,
Bapt
You're lucky, I have a box, the last CURRENT standing, leftover. i just
started there this update mess to get more gray hairs ...
Well, simply compiling gettext in the first place before doing anything
doesn't help much. apr1, apache24 and php5 fail in an epic way.
I need to recompile apr1 first, but for doing that, I had to compile
intltool, gdbm, gmake, gettext first and for security, I recompiled
also flex prior to any automated start. At least, I can update the
messy apache24 stuff (there is still an issue with PHP5, subversion
stuff around).
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
On 09/07/13 13:03, O. Hartmann wrote:
On Sat, 07 Sep 2013 00:16:16 +0200
Guido Falsi madpi...@freebsd.org wrote:
On 09/07/13 00:10, Boris Samorodov 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)?
I did see some of those. libtool takes those settings from
/usr/local/lib/*.la files, installed by ports, before this change.
Many of those files hardcode -liconv.
Usually portmaster/portupgrade are good enough at guessing the
correct order, but sometimes they mess it up, and this kind of
situation happens.
On my desktop PC I had to resort to ls -lt /usr/local/lib/*.la and
portmaster the older ones. This can be further narrowed down by
grepping for -liconv.
Founf another one that is failing:
port multimedia/mlt:
3 warnings generated.
cc -shared -o ../libmltgtk2.so factory.o consumer_gtk2.o
producer_pixbuf.o pixops.o filter_rescale.o producer_pango.o
producer_count.o filter_dynamictext.o -Wl,--no-undefined
-Wl,--as-needed -Wl,--no-undefined -Wl,--as-needed -L../../framework
-lmlt -pthread -lm -Wl,--no-undefined -Wl,--as-needed `pkg-config
--libs gtk+-2.0` `pkg-config --libs gdk-pixbuf-2.0` -L/usr/local/lib
-lexif `pkg-config --libs pangoft2` -liconv
---
/usr/bin/ld: cannot find -liconv cc: error: linker command failed with
exit code 1 (use -v to see invocation) gmake[4]: *** [../libmltgtk2.so]
Error 1 gmake[4]: Leaving directory
---
`/usr/ports/multimedia/mlt/work/mlt-0.9.0/src/modules/gtk2' gmake[3]:
*** [all] Error 1 gmake[3]: Leaving directory
`/usr/ports/multimedia/mlt/work/mlt-0.9.0/src/modules' gmake[2]: ***
[all] Error 1 gmake[2]: Leaving directory
`/usr/ports/multimedia/mlt/work/mlt-0.9.0' === Compilation failed
unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before
reporting the failure to the maintainer. *** Error code 1
Stop.
make[1]: stopped in /usr/ports/multimedia/mlt
*** Error code 1
Stop.
make: stopped in /usr/ports/multimedia/mlt
Good catch. We tried to catch all ports which hardcoded iconv in someway
but this one slipped through.
I'm preparing a fix for this one, shouldn't take too long. I'll come
back to you as soon as I have committed it.
Thanks for reporting!
--
Guido Falsi madpi...@freebsd.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
There are 13 ports using --with-iconv=${LOCALBASE}
devel/apr1
devel/apr2
devel/git
irc/epic5
lang/gauche
net-mgmt/ettercap
net/ssltunnel-client
net/yaz
net/zebra-server
textproc/libxml2
textproc/py-libxml2
www/apache22
www/apache24
and devel/glib20, print/ghostscript8, print/ghostscript9 using
--with-libiconv=gnu
--with-libiconv=native
--with-libiconv=no
--with-libiconv=no
Unfortunately Uses/iconv.mk defines only --with-libiconv(-prefix).
If Uses/iconv.mk can be extended with something like ICON_PATH, then
the 13 ports can be changed quickly to use the right iconv.
--
Regards,
olli
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
On 09/07/13 14:10, olli hauer wrote:
There are 13 ports using --with-iconv=${LOCALBASE}
devel/apr1
devel/apr2
devel/git
irc/epic5
lang/gauche
net-mgmt/ettercap
net/ssltunnel-client
net/yaz
net/zebra-server
textproc/libxml2
textproc/py-libxml2
www/apache22
www/apache24
Most of these do work anyway. I'm sure about various of these. I have
them working on my PCs. This does not mean they don't need to be tweaked
anyway, but they have lower priority.
net-mgmt/ettercap is known broken and I have it in my pipe. I'm giving
this all the time I can, but I can''t spend too much time on this right
now. I'm going to check these and fix the broken ones asap.
and devel/glib20, print/ghostscript8, print/ghostscript9 using
--with-libiconv=gnu
--with-libiconv=native
--with-libiconv=no
--with-libiconv=no
glib20 I already fixed in the big commit. uses native or gnu where
appropriate. I'll also have a look at the ghostscript ports asap, but at
least ghostscript9 I have seen it working on my PCs.
Unfortunately Uses/iconv.mk defines only --with-libiconv(-prefix).
If Uses/iconv.mk can be extended with something like ICON_PATH, then
the 13 ports can be changed quickly to use the right iconv.
Most of those will use the right iconv anyway if only one is found.
Extending iconv.mk should be discussed with portmgr, adding a variable
shouldn't be a problem though.
--
Guido Falsi madpi...@freebsd.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
x11/kdelibs4: /usr/local/include/grantlee/typeaccessor.h:70:40: error: no matching function for call to 'distance' return
After a messy iconv orgy update session, I update yesterday x11/kdelib4 successfully. After updating the OS to FreeBSD 10.0-CURRENT #2 r255356: Sat Sep 7 13:04:03 CEST 2013 amd64 today, I run today surprisingly into this error: [...] In file included from /usr/ports/x11/kdelibs4/work/kdelibs-4.10.5/kdeui/tests/proxymodeltestsuite/modeleventlogger.cpp:33: In file included from /usr/local/include/grantlee_core.h:24: In file included from /usr/local/include/grantlee_templates.h:34: In file included from /usr/local/include/grantlee/metatype.h:27: /usr/local/include/grantlee/typeaccessor.h:70:40: error: no matching function for call to 'distance' return QVariant::fromValueint( std::distance( container.begin(), container.end() ) ); [...] grantlee has also been update successfully, I recompiled it today again successfulyy, but without any success. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[QAT] r326595: 4x fail
- Update to 0.026 - Add more TEST_DEPENDS Changes:http://search.cpan.org/dist/Type-Tiny/Changes http://search.cpan.org/dist/Type-Tiny/NEWS - Build ID: 20130907102000-3023 Job owner: sunp...@freebsd.org Buildtime: 3 hours Enddate: Sat, 07 Sep 2013 13:14:26 GMT Revision: r326595 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=326595 - Port:devel/p5-Type-Tiny 0.026 Buildgroup: 9.1-QAT/amd64 Buildstatus: FAIL Buildgroup: 9.1-QAT/i386 Buildstatus: FAIL Buildgroup: 8.4-QAT/amd64 Buildstatus: FAIL Buildgroup: 8.4-QAT/i386 Buildstatus: FAIL -- Buildarchive URL: https://qat.redports.org/buildarchive/20130907102000-3023 redports https://qat.redports.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[QAT] r326596: 4x fail
- Add p5-Type-Tie 0.003 Type::Tie exports a single function: ttie. ttie ties a variable to a type constraint, ensuring that whatever values stored in the variable will conform to the type constraint. If the type constraint has coercions, these will be used if necessary to ensure values assigned to the variable conform. WWW: http://search.cpan.org/dist/Type-Tie/ - Build ID: 20130907102000-18355 Job owner: sunp...@freebsd.org Buildtime: 3 hours Enddate: Sat, 07 Sep 2013 13:29:48 GMT Revision: r326596 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=326596 - Port:devel/p5-Type-Tie 0.003 Buildgroup: 9.1-QAT/amd64 Buildstatus: FAIL Buildgroup: 9.1-QAT/i386 Buildstatus: FAIL Buildgroup: 8.4-QAT/amd64 Buildstatus: FAIL Buildgroup: 8.4-QAT/i386 Buildstatus: FAIL -- Buildarchive URL: https://qat.redports.org/buildarchive/20130907102000-18355 redports https://qat.redports.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
07.09.2013 16:27, Guido Falsi пишет:
On 09/07/13 14:10, olli hauer wrote:
There are 13 ports using --with-iconv=${LOCALBASE}
devel/apr1
devel/apr2
devel/git
irc/epic5
lang/gauche
net-mgmt/ettercap
net/ssltunnel-client
net/yaz
net/zebra-server
textproc/libxml2
textproc/py-libxml2
www/apache22
www/apache24
Most of these do work anyway. I'm sure about various of these. I have
them working on my PCs. This does not mean they don't need to be tweaked
anyway, but they have lower priority.
net-mgmt/ettercap is known broken and I have it in my pipe. I'm giving
this all the time I can, but I can''t spend too much time on this right
now. I'm going to check these and fix the broken ones asap.
Broken (at least as in does not build) is only net-mgmt/ettercap.
For the latter a have a patch (not clean to install, but the port builds
fine).
and devel/glib20, print/ghostscript8, print/ghostscript9 using
--with-libiconv=gnu
--with-libiconv=native
--with-libiconv=no
--with-libiconv=no
glib20 I already fixed in the big commit. uses native or gnu where
appropriate. I'll also have a look at the ghostscript ports asap, but at
least ghostscript9 I have seen it working on my PCs.
Unfortunately Uses/iconv.mk defines only --with-libiconv(-prefix).
If Uses/iconv.mk can be extended with something like ICON_PATH, then
the 13 ports can be changed quickly to use the right iconv.
Well, at least at net-mgmt/ettercap configure script should be fixed,
as it uses hardcode -liconv while testing.
Most of those will use the right iconv anyway if only one is found.
Extending iconv.mk should be discussed with portmgr, adding a variable
shouldn't be a problem though.
I have a (not yet tested) patch introducing ICONV_PREFIX variable,
defaults to ${LOCALBASE} and /usr respectively.
--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD Port: sdl-1.2.15_2,2 build error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I encountered an error while building the sdl12 port for FreeBSD 9.1: In file included from ./src/video/x11/SDL_x11dyn.c:96: ./src/video/x11/SDL_x11sym.h:168: error: conflicting types for '_XData32' /usr/local/include/X11/Xlibint.h:650: error: previous declaration of '_XData32' was here gmake: *** [build/SDL_x11dyn.lo] Error 1 === Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** [do-build] Error code 1 Stop in /usr/ports/devel/sdl12. *** [install] Error code 1 Stop in /usr/ports/devel/sdl12. I was able to sucessfully build it after emptying the patch file patch-src_video_x11_SDL_x11sym.h. So probably this patch should be reviewed. David -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJSK2kfAAoJEJmIEsQzdXsq7TsIAI6ijjQ7csCeF4ANd27TolLN z93T95xoM/76dy7PjyDPqKf8sXfA6QFRL15nh/vNX5qX3njs1AQhmfMxnOZmq1Eu 0DtNwl0SR7P9RAc83wJdbynbU6yv+IXw+8K5HAFHdTZj+wUQsu0tnJbUEb85j77D dG7nDl2jLn6wt8ZFdoIE7mVYUcj141zVUJ/qlGI16K0dO80UwcWbkwtGmAQL/Ttq imNOurwSY1aev3u3w21/RfD6Uu3UK1yCyi4YsKN3Ij8kXdf+qCCfuT8UasX27vzb rrqfZowOqRQHD5PBmk0QCQ41XuVfzZfbqT/pm8XwebM7PFZP4Y0Ok5dGGE19Eiw= =t/lM -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: sdl-1.2.15_2,2 build error
Hi David, On, Sat Sep 07, 2013, David Lichti wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I encountered an error while building the sdl12 port for FreeBSD 9.1: In file included from ./src/video/x11/SDL_x11dyn.c:96: ./src/video/x11/SDL_x11sym.h:168: error: conflicting types for '_XData32' /usr/local/include/X11/Xlibint.h:650: error: previous declaration of '_XData32' was here gmake: *** [build/SDL_x11dyn.lo] Error 1 === Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** [do-build] Error code 1 I can't recreate that issue. Can you tell me, which version of the xlib package is installed on your system? What does pkg_info libX11* | head -n1 say? Cheers Marcus pgp3KAb6OsrTD.pgp Description: PGP signature
Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
While proceeding in the iconv-mess, I run into a very nasty situation with some ports showing strange linker errors on most recent systems. The symptoms are present on boxes with CURRENT r255259, for instance, the error below is taken from a box which has already compiled the port in question successfully, but then I recompiled world, installed world and proceeded this morning with the port's updating mess. And the boxes in question are at FreeBSD 10.0-CURRENT #2 r255356: Sat Sep 7 13:04:03 CEST 2013 amd64 Those machines I maintain all use the very same /etc/src.conf and settings there, so issues with libc++11 et cetera must then related to the different OS revision. I see qt4-scripts and kdelibs4 failing with some strange undefined references to 'swap' in c++ classes, as well as several very severe prerequisits for kdevelop (I do not use KDE, so I simply have the kdevelopp stuff amongst necessary ports). Below the failing port textproc/libxml++26 which fails on r255356, but not on the box with r255259. On the failing system, I'm able to compile the port devel/glibmm. [...] libtool: link: c++ -Wall -O2 -pipe -O3 -march=native -fno-strict-aliasing -o examples/dom_parse_entities/.libs/dom_parse_entities examples/dom_parse_entities/main.o libxml++/.libs/libxml++-2.6.so -L/usr/local/lib /usr/local/lib/libxml2.so -L/usr/lib -lz -llzma -lm /usr/local/lib/libglibmm-2.4.so /usr/local/lib/libgmodule-2.0.so /usr/local/lib/libgobject-2.0.so /usr/local/lib/libffi.so /usr/local/lib/libglib-2.0.so -licui18n /usr/local/lib/libpcre.so /usr/local/lib/libintl.so /usr/local/lib/libsigc-2.0.so -pthread -Wl,-rpath -Wl,/usr/local/lib libtool: link: c++ -Wall -O2 -pipe -O3 -march=native -fno-strict-aliasing -o examples/dom_build/.libs/dom_build examples/dom_build/main.o libxml++/.libs/libxml++-2.6.so -L/usr/local/lib /usr/local/lib/libxml2.so -L/usr/lib -lz -llzma -lm /usr/local/lib/libglibmm-2.4.so /usr/local/lib/libgmodule-2.0.so /usr/local/lib/libgobject-2.0.so /usr/local/lib/libffi.so /usr/local/lib/libglib-2.0.so -licui18n /usr/local/lib/libpcre.so /usr/local/lib/libintl.so /usr/local/lib/libsigc-2.0.so -pthread -Wl,-rpath -Wl,/usr/local/lib /usr/local/lib/libglibmm-2.4.so: undefined reference to `sigc::internal::signal_impl::erase(std::__1::__list_iteratorsigc::slot_base, void*)' /usr/local/lib/libglibmm-2.4.so: undefined reference to `sigc::internal::signal_impl::insert(std::__1::__list_iteratorsigc::slot_base, void*, sigc::slot_base const)' /usr/local/lib/libglibmm-2.4.so: undefined reference to `sigc::internal::signal_impl::erase(std::__1::__list_iteratorsigc::slot_base, void*)/usr/local/lib/libglibmm-2.4.so: undefined reference to `sigc::internal::signal_impl::erase(std::__1::__list_iteratorsigc::slot_base, void*)' ' /usr/local/lib/libglibmm-2.4.so: /usr/local/lib/libglibmm-2.4.so: undefined reference to `sigc::internal::signal_impl::insert(std::__1::__list_iteratorsigc::slot_base, void*, sigc::slot_base const)' undefined reference to `sigc::internal::signal_impl::insert(std::__1::__list_iteratorsigc::slot_base, void*, sigc::slot_base const)' c++: error: linker command failed with exit code 1 (use -v to see invocation) gmake[2]: *** [examples/dom_parser/dom_parser] Error 1 gmake[2]: *** Waiting for unfinished jobs c++: error: linker command failed with exit code 1 (use -v to see invocation) c++: error: linker command failed with exit code 1 (use -v to see invocation) gmake[2]: *** [examples/dom_parse_entities/dom_parse_entities] Error 1 gmake[2]: *** [examples/dom_build/dom_build] Error 1 gmake[2]: Leaving directory `/usr/ports/textproc/libxml++26/work/libxml++-2.34.2' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/usr/ports/textproc/libxml++26/work/libxml++-2.34.2' === Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/textproc/libxml++26 === make failed for textproc/libxml++26 === Aborting update === Update for textproc/libxml++26 failed === Aborting update === Killing background jobs Terminated === You can restart from the point of failure with this command line: portmaster flags x11-toolkits/pangomm textproc/libxml++26 === Exiting signature.asc Description: PGP signature
Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
On Sat, 07 Sep 2013 14:27:48 +0200
Guido Falsi madpi...@freebsd.org wrote:
On 09/07/13 14:10, olli hauer wrote:
There are 13 ports using --with-iconv=${LOCALBASE}
devel/apr1
devel/apr2
devel/git
irc/epic5
lang/gauche
net-mgmt/ettercap
net/ssltunnel-client
net/yaz
net/zebra-server
textproc/libxml2
textproc/py-libxml2
www/apache22
www/apache24
Most of these do work anyway. I'm sure about various of these. I have
them working on my PCs. This does not mean they don't need to be
tweaked anyway, but they have lower priority.
net-mgmt/ettercap is known broken and I have it in my pipe. I'm
giving this all the time I can, but I can''t spend too much time on
this right now. I'm going to check these and fix the broken ones asap.
and devel/glib20, print/ghostscript8, print/ghostscript9 using
--with-libiconv=gnu
--with-libiconv=native
--with-libiconv=no
--with-libiconv=no
glib20 I already fixed in the big commit. uses native or gnu where
appropriate. I'll also have a look at the ghostscript ports asap, but
at least ghostscript9 I have seen it working on my PCs.
Unfortunately Uses/iconv.mk defines only --with-libiconv(-prefix).
If Uses/iconv.mk can be extended with something like ICON_PATH, then
the 13 ports can be changed quickly to use the right iconv.
Most of those will use the right iconv anyway if only one is found.
Extending iconv.mk should be discussed with portmgr, adding a
variable shouldn't be a problem though.
This happens in editors/abiword:
libtool: link: ( cd .libs rm -f libimp.la ln -s
../libimp.la libimp.la ) gmake[7]: Leaving directory
`/usr/ports/editors/abiword/work/abiword-2.8.6/plugins/opendocument/imp'
gmake[6]: Leaving directory
`/usr/ports/editors/abiword/work/abiword-2.8.6/plugins/opendocument/imp'
gmake[6]: Entering directory
`/usr/ports/editors/abiword/work/abiword-2.8.6/plugins/opendocument'
../../doltlibtool
--tag=CXX --mode=link c++ -O2 -pipe -O3 -march=native
-fno-strict-aliasing -lgsf-1 -lgobject-2.0 -lglib-2.0 -lintl
-L/usr/local/lib -lxml2 -lgthread-2.0 -pthread -lgobject-2.0
-L/usr/local/lib -lglib-2.0 -lintl -L../../src -labiword-2.8 -lz
-avoid-version -module -no-undefined -L/usr/local/lib -o
opendocument.la -rpath /usr/local/lib/abiword-2.8/plugins
common/libcommon.la exp/libexp.la imp/libimp.la -ljpeg
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
gmake[6]: *** [opendocument.la] Error 1 gmake[6]: Leaving directory
`/usr/ports/editors/abiword/work/abiword-2.8.6/plugins/opendocument'
gmake[5]: *** [all-recursive] Error 1 gmake[5]: Leaving directory
`/usr/ports/editors/abiword/work/abiword-2.8.6/plugins/opendocument'
gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory
`/usr/ports/editors/abiword/work/abiword-2.8.6/plugins' gmake[3]: ***
[all-recursive] Error 1 gmake[3]: Leaving directory
`/usr/ports/editors/abiword/work/abiword-2.8.6' gmake[2]: *** [all]
Error 2 gmake[2]: Leaving directory
`/usr/ports/editors/abiword/work/abiword-2.8.6' === Compilation failed
unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before
reporting the failure to the maintainer. *** Error code 1
signature.asc
Description: PGP signature
Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
On Sat, 7 Sep 2013 21:13:36 +0200 O. Hartmann ohart...@zedat.fu-berlin.de wrote: While proceeding in the iconv-mess, I run into a very nasty situation with some ports showing strange linker errors on most recent systems. The symptoms are present on boxes with CURRENT r255259, for instance, the error below is taken from a box which has already compiled the port in question successfully, but then I recompiled world, installed world and proceeded this morning with the port's updating mess. And the boxes in question are at FreeBSD 10.0-CURRENT #2 r255356: Sat Sep 7 13:04:03 CEST 2013 amd64 Those machines I maintain all use the very same /etc/src.conf and settings there, so issues with libc++11 et cetera must then related to the different OS revision. I see qt4-scripts and kdelibs4 failing with some strange undefined references to 'swap' in c++ classes, as well as several very severe prerequisits for kdevelop (I do not use KDE, so I simply have the kdevelopp stuff amongst necessary ports). Below the failing port textproc/libxml++26 which fails on r255356, but not on the box with r255259. On the failing system, I'm able to compile the port devel/glibmm. [...] libtool: link: c++ -Wall -O2 -pipe -O3 -march=native -fno-strict-aliasing -o examples/dom_parse_entities/.libs/dom_parse_entities examples/dom_parse_entities/main.o libxml++/.libs/libxml++-2.6.so -L/usr/local/lib /usr/local/lib/libxml2.so -L/usr/lib -lz -llzma -lm /usr/local/lib/libglibmm-2.4.so /usr/local/lib/libgmodule-2.0.so /usr/local/lib/libgobject-2.0.so /usr/local/lib/libffi.so /usr/local/lib/libglib-2.0.so -licui18n /usr/local/lib/libpcre.so /usr/local/lib/libintl.so /usr/local/lib/libsigc-2.0.so -pthread -Wl,-rpath -Wl,/usr/local/lib libtool: link: c++ -Wall -O2 -pipe -O3 -march=native -fno-strict-aliasing -o examples/dom_build/.libs/dom_build examples/dom_build/main.o libxml++/.libs/libxml++-2.6.so -L/usr/local/lib /usr/local/lib/libxml2.so -L/usr/lib -lz -llzma -lm /usr/local/lib/libglibmm-2.4.so /usr/local/lib/libgmodule-2.0.so /usr/local/lib/libgobject-2.0.so /usr/local/lib/libffi.so /usr/local/lib/libglib-2.0.so -licui18n /usr/local/lib/libpcre.so /usr/local/lib/libintl.so /usr/local/lib/libsigc-2.0.so -pthread -Wl,-rpath -Wl,/usr/local/lib /usr/local/lib/libglibmm-2.4.so: undefined reference to `sigc::internal::signal_impl::erase(std::__1::__list_iteratorsigc::slot_base, void*)' /usr/local/lib/libglibmm-2.4.so: undefined reference to `sigc::internal::signal_impl::insert(std::__1::__list_iteratorsigc::slot_base, void*, sigc::slot_base const)' /usr/local/lib/libglibmm-2.4.so: undefined reference to `sigc::internal::signal_impl::erase(std::__1::__list_iteratorsigc::slot_base, void*)/usr/local/lib/libglibmm-2.4.so: undefined reference to `sigc::internal::signal_impl::erase(std::__1::__list_iteratorsigc::slot_base, void*)' ' /usr/local/lib/libglibmm-2.4.so: /usr/local/lib/libglibmm-2.4.so: undefined reference to `sigc::internal::signal_impl::insert(std::__1::__list_iteratorsigc::slot_base, void*, sigc::slot_base const)' undefined reference to `sigc::internal::signal_impl::insert(std::__1::__list_iteratorsigc::slot_base, void*, sigc::slot_base const)' c++: error: linker command failed with exit code 1 (use -v to see invocation) gmake[2]: *** [examples/dom_parser/dom_parser] Error 1 gmake[2]: *** Waiting for unfinished jobs c++: error: linker command failed with exit code 1 (use -v to see invocation) c++: error: linker command failed with exit code 1 (use -v to see invocation) gmake[2]: *** [examples/dom_parse_entities/dom_parse_entities] Error 1 gmake[2]: *** [examples/dom_build/dom_build] Error 1 gmake[2]: Leaving directory `/usr/ports/textproc/libxml++26/work/libxml++-2.34.2' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/usr/ports/textproc/libxml++26/work/libxml++-2.34.2' === Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/textproc/libxml++26 === make failed for textproc/libxml++26 === Aborting update === Update for textproc/libxml++26 failed === Aborting update === Killing background jobs Terminated === You can restart from the point of failure with this command line: portmaster flags x11-toolkits/pangomm textproc/libxml++26 === Exiting This happens in devel/qt4-script only on most recent r255356. Same port, same revision of the ports-tree (326682) on a box with r255259 compiles without error. [...] In file included from ../3rdparty/javascriptcore/JavaScriptCore/API/JSBase.cpp:26: In file included from ../3rdparty/javascriptcore/JavaScriptCore/config.h:68: In file included from ../3rdparty/javascriptcore/JavaScriptCore/wtf/FastMalloc.h:27: In file included from /usr/include/c++/v1/new:56: In file included from /usr/include/c++/v1/exception:81: /usr/include/c++/v1/type_traits:3175:22:
Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
On Sat, 7 Sep 2013 21:52:11 +0200 O. Hartmann ohart...@zedat.fu-berlin.de wrote: On Sat, 7 Sep 2013 21:13:36 +0200 O. Hartmann ohart...@zedat.fu-berlin.de wrote: While proceeding in the iconv-mess, I run into a very nasty situation with some ports showing strange linker errors on most recent systems. The symptoms are present on boxes with CURRENT r255259, for instance, the error below is taken from a box which has already compiled the port in question successfully, but then I recompiled world, installed world and proceeded this morning with the port's updating mess. And the boxes in question are at FreeBSD 10.0-CURRENT #2 r255356: Sat Sep 7 13:04:03 CEST 2013 amd64 Those machines I maintain all use the very same /etc/src.conf and settings there, so issues with libc++11 et cetera must then related to the different OS revision. I see qt4-scripts and kdelibs4 failing with some strange undefined references to 'swap' in c++ classes, as well as several very severe prerequisits for kdevelop (I do not use KDE, so I simply have the kdevelopp stuff amongst necessary ports). Below the failing port textproc/libxml++26 which fails on r255356, but not on the box with r255259. On the failing system, I'm able to compile the port devel/glibmm. [...] libtool: link: c++ -Wall -O2 -pipe -O3 -march=native -fno-strict-aliasing -o examples/dom_parse_entities/.libs/dom_parse_entities examples/dom_parse_entities/main.o libxml++/.libs/libxml++-2.6.so -L/usr/local/lib /usr/local/lib/libxml2.so -L/usr/lib -lz -llzma -lm /usr/local/lib/libglibmm-2.4.so /usr/local/lib/libgmodule-2.0.so /usr/local/lib/libgobject-2.0.so /usr/local/lib/libffi.so /usr/local/lib/libglib-2.0.so -licui18n /usr/local/lib/libpcre.so /usr/local/lib/libintl.so /usr/local/lib/libsigc-2.0.so -pthread -Wl,-rpath -Wl,/usr/local/lib libtool: link: c++ -Wall -O2 -pipe -O3 -march=native -fno-strict-aliasing -o examples/dom_build/.libs/dom_build examples/dom_build/main.o libxml++/.libs/libxml++-2.6.so -L/usr/local/lib /usr/local/lib/libxml2.so -L/usr/lib -lz -llzma -lm /usr/local/lib/libglibmm-2.4.so /usr/local/lib/libgmodule-2.0.so /usr/local/lib/libgobject-2.0.so /usr/local/lib/libffi.so /usr/local/lib/libglib-2.0.so -licui18n /usr/local/lib/libpcre.so /usr/local/lib/libintl.so /usr/local/lib/libsigc-2.0.so -pthread -Wl,-rpath -Wl,/usr/local/lib /usr/local/lib/libglibmm-2.4.so: undefined reference to `sigc::internal::signal_impl::erase(std::__1::__list_iteratorsigc::slot_base, void*)' /usr/local/lib/libglibmm-2.4.so: undefined reference to `sigc::internal::signal_impl::insert(std::__1::__list_iteratorsigc::slot_base, void*, sigc::slot_base const)' /usr/local/lib/libglibmm-2.4.so: undefined reference to `sigc::internal::signal_impl::erase(std::__1::__list_iteratorsigc::slot_base, void*)/usr/local/lib/libglibmm-2.4.so: undefined reference to `sigc::internal::signal_impl::erase(std::__1::__list_iteratorsigc::slot_base, void*)' ' /usr/local/lib/libglibmm-2.4.so: /usr/local/lib/libglibmm-2.4.so: undefined reference to `sigc::internal::signal_impl::insert(std::__1::__list_iteratorsigc::slot_base, void*, sigc::slot_base const)' undefined reference to `sigc::internal::signal_impl::insert(std::__1::__list_iteratorsigc::slot_base, void*, sigc::slot_base const)' c++: error: linker command failed with exit code 1 (use -v to see invocation) gmake[2]: *** [examples/dom_parser/dom_parser] Error 1 gmake[2]: *** Waiting for unfinished jobs c++: error: linker command failed with exit code 1 (use -v to see invocation) c++: error: linker command failed with exit code 1 (use -v to see invocation) gmake[2]: *** [examples/dom_parse_entities/dom_parse_entities] Error 1 gmake[2]: *** [examples/dom_build/dom_build] Error 1 gmake[2]: Leaving directory `/usr/ports/textproc/libxml++26/work/libxml++-2.34.2' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/usr/ports/textproc/libxml++26/work/libxml++-2.34.2' === Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/textproc/libxml++26 === make failed for textproc/libxml++26 === Aborting update === Update for textproc/libxml++26 failed === Aborting update === Killing background jobs Terminated === You can restart from the point of failure with this command line: portmaster flags x11-toolkits/pangomm textproc/libxml++26 === Exiting This happens in devel/qt4-script only on most recent r255356. Same port, same revision of the ports-tree (326682) on a box with r255259 compiles without error. [...] In file included from ../3rdparty/javascriptcore/JavaScriptCore/API/JSBase.cpp:26: In file included from ../3rdparty/javascriptcore/JavaScriptCore/config.h:68: In file included from
Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
On Sat, 07 Sep 2013 13:34:25 +0200
Guido Falsi madpi...@freebsd.org wrote:
On 09/07/13 13:03, O. Hartmann wrote:
On Sat, 07 Sep 2013 00:16:16 +0200
Guido Falsi madpi...@freebsd.org wrote:
On 09/07/13 00:10, Boris Samorodov 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)?
I did see some of those. libtool takes those settings from
/usr/local/lib/*.la files, installed by ports, before this change.
Many of those files hardcode -liconv.
Usually portmaster/portupgrade are good enough at guessing the
correct order, but sometimes they mess it up, and this kind of
situation happens.
On my desktop PC I had to resort to ls -lt /usr/local/lib/*.la and
portmaster the older ones. This can be further narrowed down by
grepping for -liconv.
Founf another one that is failing:
port multimedia/mlt:
3 warnings generated.
cc -shared -o ../libmltgtk2.so factory.o consumer_gtk2.o
producer_pixbuf.o pixops.o filter_rescale.o producer_pango.o
producer_count.o filter_dynamictext.o -Wl,--no-undefined
-Wl,--as-needed -Wl,--no-undefined -Wl,--as-needed -L../../framework
-lmlt -pthread -lm -Wl,--no-undefined -Wl,--as-needed `pkg-config
--libs gtk+-2.0` `pkg-config --libs gdk-pixbuf-2.0`
-L/usr/local/lib -lexif `pkg-config --libs pangoft2` -liconv
---
/usr/bin/ld: cannot find -liconv cc: error: linker command failed
with exit code 1 (use -v to see invocation) gmake[4]: ***
[../libmltgtk2.so] Error 1 gmake[4]: Leaving directory
---
`/usr/ports/multimedia/mlt/work/mlt-0.9.0/src/modules/gtk2'
gmake[3]: *** [all] Error 1 gmake[3]: Leaving directory
`/usr/ports/multimedia/mlt/work/mlt-0.9.0/src/modules' gmake[2]: ***
[all] Error 1 gmake[2]: Leaving directory
`/usr/ports/multimedia/mlt/work/mlt-0.9.0' === Compilation failed
unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before
reporting the failure to the maintainer. *** Error code 1
Stop.
make[1]: stopped in /usr/ports/multimedia/mlt
*** Error code 1
Stop.
make: stopped in /usr/ports/multimedia/mlt
Good catch. We tried to catch all ports which hardcoded iconv in
someway but this one slipped through.
I'm preparing a fix for this one, shouldn't take too long. I'll come
back to you as soon as I have committed it.
Thanks for reporting!
Here is another sticky bummer, multimedia/xine and multimedia/libxine:
[...]
mv -f .deps/videowin.Tpo .deps/videowin.Po
cc -I/usr/local/include -I/usr/local/include
-I/usr/include/readline -I../../src/xitk/xine-toolkit -Wall
-D_FILE_OFFSET_BITS=64 -Wpointer-arith -Wnested-externs -Wcast-align
-Wchar-subscripts -Wmissing-declarations
v10 pkg question, maybe
#/# find /var/db/pkg -type d -name p5* | xargs -J % find -type f -name
+CONTENTS -exec grep -H 5.12 {} \; | grep pm | gtr -s \/ \n | grep p5 |
sort | uniq | xargs -J % portmaster -d -B -P -i -g % yell || yell
If one has gtr (gnu tr) installed, that may work if one has /var/db/pkg...
I had an issue where pkg_which turned up ? for all the perl files it usually
worked on in /usr/local/lib/perl5/site_perl (etc)
to upgrade, say, 5.12.4 to 5.12.5... suddenly failing a bit into the 5.12.5
5.14.4 upgrade, meaning each port had to be
entered manually.
That long CLI pipe at the top is working handily. ( midst of it, a head -110 ,
head -140, head -170 so make its failures
manageble on restart)
And one inserts | grep -v tkdb | , for instance, for p5- ports which won't
rebuild at the moment.
In fact that script is working way better than any other perl upgrade I recall
doing that required an UPDATING course of action.
So I am wondering it someone who uses /pkg/ can craft an equivalent CLI, test
it, and eventually it or its equivalant could be
placed either in the port, or in UPDATING so persons who have many ports could
upgrade leisurely in a few hours rather than
kludgedly over many more hours than the few.
Thanks if anyone has the time... and expertise and experience to look into the
situation.
J. Bouquet
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: x11/kdelibs4: /usr/local/include/grantlee/typeaccessor.h:70:40: error: no matching function for call to 'distance' return
O. Hartmann ohart...@zedat.fu-berlin.de writes: After a messy iconv orgy update session, I update yesterday x11/kdelib4 successfully. After updating the OS to FreeBSD 10.0-CURRENT #2 r255356: Sat Sep 7 13:04:03 CEST 2013 amd64 today, I run today surprisingly into this error: [...] In file included from /usr/ports/x11/kdelibs4/work/kdelibs-4.10.5/kdeui/tests/proxymodeltestsuite/modeleventlogger.cpp:33: In file included from /usr/local/include/grantlee_core.h:24: In file included from /usr/local/include/grantlee_templates.h:34: In file included from /usr/local/include/grantlee/metatype.h:27: /usr/local/include/grantlee/typeaccessor.h:70:40: error: no matching function for call to 'distance' return QVariant::fromValueint( std::distance( container.begin(), container.end() ) ); [...] grantlee has also been update successfully, I recompiled it today again successfulyy, but without any success. Are you using libc++ and is the error message much bigger than that? I've fixed that one in Qt and the patch is part of 4.8.5. I'll see how much work is left to bring in 4.8.5 into ports. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
bsd.port.pre.mk vs bsd.port.options.mk
I have port that does something like
.include bsd.port.pre.mk
.if ${ARCH} == ...
...
.endif
.include bsd.port.post.mk
A while back somebody submitted a PR asking me to replace bsd.port.pre.mk
with bsd.port.options.mk, because it also makes ARCH available and
is far less expensive.
Now, a priori it is not clear to me that including options.mk is
actually cheaper than pre.mk. And it seems odd to include options.mk
but then not use any part of the options framework. The Porter's
Handbook explicitly mentions ARCH as one of the variables provided
by pre.mk.
What's the preferred way to handle this?
--
Christian naddy Weisgerber na...@mips.inka.de
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[QAT] r326683: 4x leftovers, 4x ignored: not for the general public. maintainer only supports developers of apr, 44x success
Introduce variable ICONV_PREFIX at Mk/Uses/iconv.mk. The default for
pre 100043 is ${LOCALBASE} and /usr otherwise. Convert all ports to
new variable usage.
Approved by:portmgr (bapt, implicit)
-
Build ID: 20130907195001-54899
Job owner: b...@freebsd.org
Buildtime: 4 hours
Enddate: Sun, 08 Sep 2013 00:03:03 GMT
Revision: r326683
Repository:
https://svnweb.freebsd.org/ports?view=revisionrevision=326683
-
Port:devel/apr1 1.4.8.1.5.2
Buildgroup: 9.1-QAT/amd64
Buildstatus: SUCCESS
Log:
https://qat.redports.org//~b...@freebsd.org/20130907195001-54899-183520/apr-1.4.8.1.5.2.log
Buildgroup: 9.1-QAT/i386
Buildstatus: SUCCESS
Log:
https://qat.redports.org//~b...@freebsd.org/20130907195001-54899-183521/apr-1.4.8.1.5.2.log
Buildgroup: 8.4-QAT/amd64
Buildstatus: SUCCESS
Log:
https://qat.redports.org//~b...@freebsd.org/20130907195001-54899-183522/apr-1.4.8.1.5.2.log
Buildgroup: 8.4-QAT/i386
Buildstatus: SUCCESS
Log:
https://qat.redports.org//~b...@freebsd.org/20130907195001-54899-183523/apr-1.4.8.1.5.2.log
-
Port:devel/apr2 2.0.20110821151329_2
Buildgroup: 9.1-QAT/amd64
Buildstatus: IGNORED: NOT FOR THE GENERAL PUBLIC. MAINTAINER ONLY
SUPPORTS DEVELOPERS OF APR
Buildgroup: 9.1-QAT/i386
Buildstatus: IGNORED: NOT FOR THE GENERAL PUBLIC. MAINTAINER ONLY
SUPPORTS DEVELOPERS OF APR
Buildgroup: 8.4-QAT/amd64
Buildstatus: IGNORED: NOT FOR THE GENERAL PUBLIC. MAINTAINER ONLY
SUPPORTS DEVELOPERS OF APR
Buildgroup: 8.4-QAT/i386
Buildstatus: IGNORED: NOT FOR THE GENERAL PUBLIC. MAINTAINER ONLY
SUPPORTS DEVELOPERS OF APR
-
Port:devel/git 1.8.4
Buildgroup: 9.1-QAT/amd64
Buildstatus: LEFTOVERS
Log:
https://qat.redports.org//~b...@freebsd.org/20130907195001-54899-183528/git-1.8.4.log
Buildgroup: 9.1-QAT/i386
Buildstatus: LEFTOVERS
Log:
https://qat.redports.org//~b...@freebsd.org/20130907195001-54899-183529/git-1.8.4.log
Buildgroup: 8.4-QAT/amd64
Buildstatus: LEFTOVERS
Log:
https://qat.redports.org//~b...@freebsd.org/20130907195001-54899-183530/git-1.8.4.log
Buildgroup: 8.4-QAT/i386
Buildstatus: LEFTOVERS
Log:
https://qat.redports.org//~b...@freebsd.org/20130907195001-54899-183531/git-1.8.4.log
-
Port:irc/epic5 1.1.6
Buildgroup: 9.1-QAT/amd64
Buildstatus: SUCCESS
Log:
https://qat.redports.org//~b...@freebsd.org/20130907195001-54899-183532/epic5-1.1.6.log
Buildgroup: 9.1-QAT/i386
Buildstatus: SUCCESS
Log:
https://qat.redports.org//~b...@freebsd.org/20130907195001-54899-183533/epic5-1.1.6.log
Buildgroup: 8.4-QAT/amd64
Buildstatus: SUCCESS
Log:
https://qat.redports.org//~b...@freebsd.org/20130907195001-54899-183534/epic5-1.1.6.log
Buildgroup: 8.4-QAT/i386
Buildstatus: SUCCESS
Log:
https://qat.redports.org//~b...@freebsd.org/20130907195001-54899-183535/epic5-1.1.6.log
-
Port:lang/gauche 0.9.3.3_1
Buildgroup: 9.1-QAT/amd64
Buildstatus: SUCCESS
Log:
https://qat.redports.org//~b...@freebsd.org/20130907195001-54899-183536/gauche-0.9.3.3_1.log
Buildgroup: 9.1-QAT/i386
Buildstatus: SUCCESS
Log:
https://qat.redports.org//~b...@freebsd.org/20130907195001-54899-183537/gauche-0.9.3.3_1.log
Buildgroup: 8.4-QAT/amd64
Buildstatus: SUCCESS
Log:
https://qat.redports.org//~b...@freebsd.org/20130907195001-54899-183538/gauche-0.9.3.3_1.log
Buildgroup: 8.4-QAT/i386
Buildstatus: SUCCESS
Log:
https://qat.redports.org//~b...@freebsd.org/20130907195001-54899-183539/gauche-0.9.3.3_1.log
-
Port:net-mgmt/ettercap 0.7.4.1_3,1
Buildgroup: 9.1-QAT/amd64
Buildstatus: SUCCESS
Log:
https://qat.redports.org//~b...@freebsd.org/20130907195001-54899-183540/ettercap-gtk2-0.7.4.1_3,1.log
Buildgroup: 9.1-QAT/i386
Buildstatus: SUCCESS
Log:
https://qat.redports.org//~b...@freebsd.org/20130907195001-54899-183541/ettercap-gtk2-0.7.4.1_3,1.log
Buildgroup: 8.4-QAT/amd64
Buildstatus: SUCCESS
Log:
Paper cup,Drinking straws, fork, Knife and Other cutlery Supply shared an album with you.
Dear Manager: We are a company focused on food package. and What we do is Just Helping you to save your cost. Now we can supply : 1. Single wall paper cup. Double PE .Hot Paper cups. Double Wall paper cups. Cold Drinking cups, Ripple Wall cups. Paper box. 2. Drinking straws , Flexible straws. Straight straws. 3. Plastic cups. PET cold cups 4. Plastic spoon. fork, Knife and Other cutlery. We know that buiness include: Quality. Price. Delivery time. Payment Terms. And Service. We welcome you to do customized cups and any enquiries. samples for free. Best Regards Jeff https://picasaweb.google.com/lh/sredir?uname=107068765394658469133target=ALBUMid=5920136760001545889authkey=Gv1sRgCKjL8YWKybHW2gEinvite=CKKUp68Mfeat=email ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
