date:20130908

Re: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous

2013-09-08 Thread O. Hartmann

On Sat, 7 Sep 2013 22:49:54 GMT
rak...@freebsd.org wrote:

 Synopsis: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22:
 error: call to 'swap' is ambiguous
 
 State-Changed-From-To: open-patched
 State-Changed-By: rakuco
 State-Changed-When: Sat Sep 7 22:47:43 UTC 2013
 State-Changed-Why: 
 I don't think the previous version worked.
 
 From your description, it looks like you've switched to building with
 libc++ whereas libstdc++ was being used before.
 
 The upcoming Qt 4.8.5 plus a few patches which only made it to 4.8.6
 (but we've backported) will finally make Qt build with libc++.
 
 We've just sent an exp-run request for Qt 4.8.5, and will hopefully
 fix all these errors once it is committed.
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=181913


I build the world/kernel since early this year with 

CXXFLAGS+=  -stdlib=libc++
CXXFLAGS+=  -std=c++11


in /etc/src.conf. I do not use those flags
in /etc/make.conf! /etc/src.conf is supposed to target ONLY
the /usr/src world, not the ports - this is as I interpret the man page
for /etc/src.conf and it would be logical. But this rule/thinking seems
to be broken by some includes from /usr/ports/Mk ingredients.

I can assure that I didn't switch anything to build the ports but
rebuilding world and then restarting building. Something must have
changed since then in the logic of how libc++ slipped in instead of
of libstdc++.

What I did was a make delete-old-files, which deleted several GNU gcc
stuff on all CURRENT boxes. I did not see that any lib got killed after
I tried make delete-old-libs. And I did not check whether libstdc++
is still being built.

There are many other occasions where now c++ errors occur and I guess
those ports need to be reported in one by one via PR?


signature.asc
Description: PGP signature

net/openldap24-server: libtool: compile: gcc -g -O2 -Wall -DDO_SAMBA -I../../../inc [...] eval: gcc: not found *** Error code 1

2013-09-08 Thread O. Hartmann


After having built a world on CURRENT r255356 and having done make
delete-old the outdated gnuish compiler stuff gets deleted. After
that, port net/openldap[-sasl]-server rejects to compile due to the
shown error.

Somehwere the compiler seems to be hardcoded.



[...] 
--- all-common ---
for page in slapacl.8slapadd.8
slapauth.8  slapcat.8   slapd.8
slapdn.8   slapindex.8  slappasswd.8
slapschema.8slaptest.8; do  sed -e s%LDVERSION%2.4.36%
-e 's%ETCDIR%/usr/local/etc/openldap%g'  -e 's%LOCALSTATEDIR%/var/db%'
-e 's%SYSCONFDIR%/usr/local/etc/openldap%'  -e
's%DATADIR%/usr/local/share/openldap%'  -e
's%SBINDIR%/usr/local/sbin%'  -e 's%BINDIR%/usr/local/bin%'  -e
's%LIBDIR%/usr/local/lib%'  -e 's%LIBEXECDIR%/usr/local/libexec%'  -e
's%MODULEDIR%/usr/local/libexec/openldap%'  -e
's%RELEASEDATE%2013/08/17%'  ./$page  | (cd .; soelim -)  $page.tmp;
done /usr/local/bin/libtool --mode=compile gcc -g -O2 -Wall -DDO_SAMBA
-I../../../include -I../../../include -I../../../servers/slapd
-I/usr/heimdal/include  -c smbk5pwd.c libtool: compile:  gcc -g -O2
-Wall -DDO_SAMBA -I../../../include -I../../../include
-I../../../servers/slapd -I/usr/heimdal/include -c smbk5pwd.c  -fPIC
-DPIC -o .libs/smbk5pwd.o eval: gcc: not found *** Error code 1

Stop.
make[2]: stopped
in 
/usr/ports/net/openldap24-server/work/openldap-2.4.36/contrib/slapd-modules/smbk5pwd
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/net/openldap24-server
*** Error code 1

Stop.
make: stopped in /usr/ports/net/openldap24-server

=== make failed for net/openldap24-server
=== Aborting update

=== Killing background jobs


signature.asc
Description: PGP signature

Re: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous

2013-09-08 Thread Boris Samorodov

08.09.2013 10:14, O. Hartmann пишет:

 I can assure that I didn't switch anything to build the ports but
 rebuilding world and then restarting building. Something must have
 changed since then in the logic of how libc++ slipped in instead of
 of libstdc++.
 
 What I did was a make delete-old-files, which deleted several GNU gcc
 stuff on all CURRENT boxes. I did not see that any lib got killed after
 I tried make delete-old-libs. And I did not check whether libstdc++
 is still being built.

Yes, recently gcc was switched off by default at CURRENT, so libc++
is used both for the system and ports.

 There are many other occasions where now c++ errors occur and I guess
 those ports need to be reported in one by one via PR?

Guess so. Preferrable with a patch. ;-)

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

Re: bsd.port.pre.mk vs bsd.port.options.mk

2013-09-08 Thread Jason Helfman

On Sat, Sep 7, 2013 at 2:42 PM, Christian Weisgerber na...@mips.inka.dewrote:

 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


It is preferred to evaluate ARCH with bsd.port.options.mk.

-jgh



-- 
Jason Helfman  | FreeBSD Committer
j...@freebsd.org | http://people.freebsd.org/~jgh  | 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

Troubles with dependencies (file -L is broken?)

2013-09-08 Thread Maxim Sobolev

Hi,

I am trying to portupgrade my subversion and it keeps trying to install
databases/db42 over already installed version (same version), missing the
shared library dependency.

Adding some debug into bsd.port.mk, I see:

===   subversion-1.8.3 depends on package: libtool=2.4 - found
set -x; set -e ;  for i in libdb-4.2.so:/usr/ports/databases/db42; do
lib=${i%%:*} ;  dir=${i#*:}  ;  target=install;  depends_args=;  echo
-n ===   subversion-1.8.3 depends on shared library: ${lib} ;  found=0
;  dirs=/lib /usr/lib /usr/local/lib `/bin/cat
/usr/local/libdata/ldconfig/* 2/dev/null || : ` ;  for libdir in $dirs;
do  test -f ${libdir}/${lib} || continue;  if [ -x /usr/bin/file ]; then  [
`file -b -L --mime-type ${libdir}/${lib}` = application/x-sharedlib ] ||
continue ;  fi ;  found=1 ;  echo  - found;  done ;  if [ ${found} -eq 0
]; then  echo  - not found;  echo ===Verifying for $lib in $dir;
if [ ! -d $dir ] ; then  echo = No directory for $lib.
Skipping..;  else  if [ -n  -o -n  ]; then  subpkgfile=`(cd $dir; make
$depends_args -V PKGFILE)`;  subpkgname=${subpkgfile%-*} ;
subpkgname=${subpkgname##*/} ;  if [ -r ${subpkgfile} -a $target =
install ]; then  echo ===   Installing existing package
${subpkgfile};  if [ -n  -a ${subpkgname} = pkg ]; then  [ -d
/usr/ports/devel/subversion/work ] || /bin/mkdir -p
/usr/ports/devel/subversion/work ;  /usr/bin/tar xf ${subpkgfile} -C
/usr/ports/devel/subversion/work -s ,/.*/,,g */pkg-static ;
/usr/ports/devel/subversion/work/pkg-static add ${subpkgfile};  /bin/rm -f
/usr/ports/devel/subversion/work/pkg-static;  else  /usr/sbin/pkg_add
${subpkgfile};  fi;  elif [ -n  -a ${target} = install ]; then  echo
===   subversion-1.8.3 depends on package: ${subpkgfile} - not found;
echo ===   USE_PACKAGE_DEPENDS_ONLY set - will not build from source;
exit 1;  else  (cd $dir; make -DINSTALLS_DEPENDS $target $depends_args) ;
fi;  else  (cd $dir; make -DINSTALLS_DEPENDS $target $depends_args) ;  fi;
echo ===   Returning to build of subversion-1.8.3;  fi ;  fi ;  done
+ set -e
+ lib=libdb-4.2.so
+ dir=/usr/ports/databases/db42
+ target=install
+ depends_args=''
+ echo -n '===   subversion-1.8.3 depends on shared library: libdb-4.2.so'
===   subversion-1.8.3 depends on shared library: libdb-4.2.so+ found=0
+ /bin/cat /usr/local/libdata/ldconfig/compat7x
/usr/local/libdata/ldconfig/mysql /usr/local/libdata/ldconfig/portupgrade
/usr/local/libdata/ldconfig/pth
+ dirs='/lib /usr/lib /usr/local/lib /usr/local/lib/compat
/usr/local/lib/mysql
/usr/local/lib/compat/pkg
/usr/local/lib/pth'
+ test -f /lib/libdb-4.2.so
+ continue
+ test -f /usr/lib/libdb-4.2.so
+ continue
+ test -f /usr/local/lib/libdb-4.2.so
+ [ -x /usr/bin/file ]
+ file -b -L --mime-type /usr/local/lib/libdb-4.2.so
+ [ inode/symlink = application/x-sharedlib ]
+ continue
+ test -f /usr/local/lib/compat/libdb-4.2.so
+ continue
+ test -f /usr/local/lib/mysql/libdb-4.2.so
+ continue
+ test -f /usr/local/lib/compat/pkg/libdb-4.2.so
+ continue
+ test -f /usr/local/lib/pth/libdb-4.2.so
+ continue
+ [ 0 -eq 0 ]
+ echo ' - not found'
 - not found
+ echo '===Verifying for libdb-4.2.so in /usr/ports/databases/db42'
===Verifying for libdb-4.2.so in /usr/ports/databases/db42

So, file(1) call is the culprit here. Trying to reproduce in the console:

[sobomax@pioneer ~]$ file -b -L --mime-type /usr/local/lib/libdb-4.2.so
inode/symlink

However:

[sobomax@pioneer ~]$ hexdump -C /usr/local/lib/libdb-4.2.so | head -n 20
  7f 45 4c 46 02 01 01 09  00 00 00 00 00 00 00 00
|.ELF|
0010  03 00 3e 00 01 00 00 00  d0 40 02 00 00 00 00 00
|...п@..|
0020  40 00 00 00 00 00 00 00  b8 a6 0e 00 00 00 00 00
|@...╦і..|
0030  00 00 00 00 40 00 38 00  05 00 40 00 1d 00 1a 00  |@.8...@
.|
0040  01 00 00 00 05 00 00 00  00 00 00 00 00 00 00 00
||
0050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
||
0060  dc 45 0e 00 00 00 00 00  dc 45 0e 00 00 00 00 00
|эE..эE..|
0070  00 00 20 00 00 00 00 00  01 00 00 00 06 00 00 00  |..
.|
0080  00 50 0e 00 00 00 00 00  00 50 2e 00 00 00 00 00
|.P...P..|
0090  00 50 2e 00 00 00 00 00  fc 36 00 00 00 00 00 00
|.P..Э6..|
00a0  d8 3a 00 00 00 00 00 00  00 00 20 00 00 00 00 00  |ь:
.|
00b0  02 00 00 00 06 00 00 00  e8 54 0e 00 00 00 00 00
|ХT..|
00c0  e8 54 2e 00 00 00 00 00  e8 54 2e 00 00 00 00 00
|ХT..ХT..|
00d0  a0 01 00 00 00 00 00 00  a0 01 00 00 00 00 00 00
|═...═...|
00e0  08 00 00 00 00 00 00 00  50 e5 74 64 04 00 00 00
|PЕtd|
00f0  5c 39 0d 00 00 00 00 00  5c 39 0d 00 00 00 00 00
|\9..\9..|
0100  5c 39 0d 00 00 00 00 00  b4 34 00 00 00 00 00 00
|\9..Є4..|
0110  b4 34 00 00 00 00 00 00  04 00 00 00 00 00 00 00
|Є4..|

The culprit is that /usr/local/lib/libdb-4.2.so is a symlink to another
symlink to another symlink etc, so that my guess is

Re: Troubles with dependencies (file -L is broken?)

2013-09-08 Thread Maxim Sobolev

P.S. This is fresh 9.2-RC3 with /usr on ZFS.

-Maxim


On Sun, Sep 8, 2013 at 12:09 AM, Maxim Sobolev sobo...@freebsd.org wrote:

 Hi,

 I am trying to portupgrade my subversion and it keeps trying to install
 databases/db42 over already installed version (same version), missing the
 shared library dependency.

 Adding some debug into bsd.port.mk, I see:

 ===   subversion-1.8.3 depends on package: libtool=2.4 - found
 set -x; set -e ;  for i in libdb-4.2.so:/usr/ports/databases/db42; do
 lib=${i%%:*} ;  dir=${i#*:}  ;  target=install;  depends_args=;  echo
 -n ===   subversion-1.8.3 depends on shared library: ${lib} ;  found=0
 ;  dirs=/lib /usr/lib /usr/local/lib `/bin/cat
 /usr/local/libdata/ldconfig/* 2/dev/null || : ` ;  for libdir in $dirs;
 do  test -f ${libdir}/${lib} || continue;  if [ -x /usr/bin/file ]; then  [
 `file -b -L --mime-type ${libdir}/${lib}` = application/x-sharedlib ] ||
 continue ;  fi ;  found=1 ;  echo  - found;  done ;  if [ ${found} -eq 0
 ]; then  echo  - not found;  echo ===Verifying for $lib in $dir;
 if [ ! -d $dir ] ; then  echo = No directory for $lib.
 Skipping..;  else  if [ -n  -o -n  ]; then  subpkgfile=`(cd $dir; make
 $depends_args -V PKGFILE)`;  subpkgname=${subpkgfile%-*} ;
 subpkgname=${subpkgname##*/} ;  if [ -r ${subpkgfile} -a $target =
 install ]; then  echo ===   Installing existing package
 ${subpkgfile};  if [ -n  -a ${subpkgname} = pkg ]; then  [ -d
 /usr/ports/devel/subversion/work ] || /bin/mkdir -p
 /usr/ports/devel/subversion/work ;  /usr/bin/tar xf ${subpkgfile} -C
 /usr/ports/devel/subversion/work -s ,/.*/,,g */pkg-static ;
 /usr/ports/devel/subversion/work/pkg-static add ${subpkgfile};  /bin/rm -f
 /usr/ports/devel/subversion/work/pkg-static;  else  /usr/sbin/pkg_add
 ${subpkgfile};  fi;  elif [ -n  -a ${target} = install ]; then  echo
 ===   subversion-1.8.3 depends on package: ${subpkgfile} - not found;
 echo ===   USE_PACKAGE_DEPENDS_ONLY set - will not build from source;
 exit 1;  else  (cd $dir; make -DINSTALLS_DEPENDS $target $depends_args) ;
 fi;  else  (cd $dir; make -DINSTALLS_DEPENDS $target $depends_args) ;  fi;
 echo ===   Returning to build of subversion-1.8.3;  fi ;  fi ;  done
 + set -e
 + lib=libdb-4.2.so
 + dir=/usr/ports/databases/db42
 + target=install
 + depends_args=''
 + echo -n '===   subversion-1.8.3 depends on shared library: libdb-4.2.so
 '
 ===   subversion-1.8.3 depends on shared library: libdb-4.2.so+ found=0
 + /bin/cat /usr/local/libdata/ldconfig/compat7x
 /usr/local/libdata/ldconfig/mysql /usr/local/libdata/ldconfig/portupgrade
 /usr/local/libdata/ldconfig/pth
 + dirs='/lib /usr/lib /usr/local/lib /usr/local/lib/compat
 /usr/local/lib/mysql
 /usr/local/lib/compat/pkg
 /usr/local/lib/pth'
 + test -f /lib/libdb-4.2.so
 + continue
 + test -f /usr/lib/libdb-4.2.so
 + continue
 + test -f /usr/local/lib/libdb-4.2.so
 + [ -x /usr/bin/file ]
 + file -b -L --mime-type /usr/local/lib/libdb-4.2.so
 + [ inode/symlink = application/x-sharedlib ]
 + continue
 + test -f /usr/local/lib/compat/libdb-4.2.so
 + continue
 + test -f /usr/local/lib/mysql/libdb-4.2.so
 + continue
 + test -f /usr/local/lib/compat/pkg/libdb-4.2.so
 + continue
 + test -f /usr/local/lib/pth/libdb-4.2.so
 + continue
 + [ 0 -eq 0 ]
 + echo ' - not found'
  - not found
 + echo '===Verifying for libdb-4.2.so in /usr/ports/databases/db42'
 ===Verifying for libdb-4.2.so in /usr/ports/databases/db42

 So, file(1) call is the culprit here. Trying to reproduce in the console:

 [sobomax@pioneer ~]$ file -b -L --mime-type /usr/local/lib/libdb-4.2.so
 inode/symlink

 However:

 [sobomax@pioneer ~]$ hexdump -C /usr/local/lib/libdb-4.2.so | head -n 20
   7f 45 4c 46 02 01 01 09  00 00 00 00 00 00 00 00
 |.ELF|
 0010  03 00 3e 00 01 00 00 00  d0 40 02 00 00 00 00 00
 |...п@..|
 0020  40 00 00 00 00 00 00 00  b8 a6 0e 00 00 00 00 00
 |@...╦і..|
 0030  00 00 00 00 40 00 38 00  05 00 40 00 1d 00 1a 00  |@.8...@
 .|
 0040  01 00 00 00 05 00 00 00  00 00 00 00 00 00 00 00
 ||
 0050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
 ||
 0060  dc 45 0e 00 00 00 00 00  dc 45 0e 00 00 00 00 00
 |эE..эE..|
 0070  00 00 20 00 00 00 00 00  01 00 00 00 06 00 00 00  |..
 .|
 0080  00 50 0e 00 00 00 00 00  00 50 2e 00 00 00 00 00
 |.P...P..|
 0090  00 50 2e 00 00 00 00 00  fc 36 00 00 00 00 00 00
 |.P..Э6..|
 00a0  d8 3a 00 00 00 00 00 00  00 00 20 00 00 00 00 00  |ь:
 .|
 00b0  02 00 00 00 06 00 00 00  e8 54 0e 00 00 00 00 00
 |ХT..|
 00c0  e8 54 2e 00 00 00 00 00  e8 54 2e 00 00 00 00 00
 |ХT..ХT..|
 00d0  a0 01 00 00 00 00 00 00  a0 01 00 00 00 00 00 00
 |═...═...|
 00e0  08 00 00 00 00 00 00 00  50 e5 74 64 04 00 00 00
 |PЕtd|
 00f0  5c 39 0d 00 00 00 00 00  5c 39 0d 00 00 00 00 00
 |\9..\9..|
 0100  5c 39 0d 00 00 00 00 00  b4 34 00 00

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

2013-09-08 Thread Guido Falsi


On 09/07/13 21:46, O. Hartmann wrote:

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



This one looks like you still have some old libtoool archive which 
references libiconv laying around.


Can you try again this command line(I rewrite here for convenience):

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

and force rebuild of any port which still shows up?

If none shows up (which would be strange, but I can't exclude anything) 
Hope is not lost and there are still some things we can try.


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

2013-09-08 Thread O. Hartmann

On Sun, 08 Sep 2013 10:44:01 +0200
Guido Falsi madpi...@freebsd.org wrote:

 On 09/07/13 21:46, O. Hartmann wrote:
  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
 
 
 This one looks like you still have some old libtoool archive which 
 references libiconv laying around.
 
 Can you try again this command line(I rewrite here for convenience):
 
 find /usr/local/lib -name '*.la' -exec grep -qi iconv {} \; -print |
 xargs -n 1 pkg which -oq | sort -u
 
 and force rebuild of any port which still shows up?
 
 If none shows up (which would be strange, but I can't exclude
 anything) Hope is not lost and there are still some things we can try.
 

On one box, the command sequence (thanks for being redundant, I didn't
find the previous email with the sequence within) reveals:

converters/psiconv
editors/abiword
math/gnumeric

Deleteing psiconv and gnumeric makes the sequence not showing both
ports again, but then, installing gnumeric again, which reels in
psiconv, the output of the command sequence is a s shown. Something is
strange here ... Another prerequisite port with oldish iconv reliances?



signature.asc
Description: PGP signature

libiconv.a(iconv.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object

2013-09-08 Thread Jeremie Le Hen

Hi,

(Please Cc: me when replying, I'm not subscribed.)

I created a fresh FreeBSD 9.1-RELEASE amd64 jail.  No installed ports.

I cannot build devel/gettext.  Does anyone experience the same problem?
I invariably run into the following problem:

libtool: link: cc -shared  -fPIC -DPIC  .libs/bindtextdom.o .libs/dcgettext.o 
.libs/dgettext.o .libs/gettext.o .libs/finddomain.o .libs/hash-string.o 
.libs/loadmsgcat.o .libs/localealias.o .libs/textdomain.o .libs/l10nflist.o 
.libs/explodename.o .libs/dcigettext.o .libs/dcngettext.o .libs/dngettext.o 
.libs/ngettext.o .libs/plural.o .libs/plural-exp.o .libs/localcharset.o 
.libs/threadlib.o .libs/lock.o .libs/relocatable.o .libs/langprefs.o 
.libs/localename.o .libs/log.o .libs/printf.o .libs/setlocale.o .libs/version.o 
.libs/xsize.o .libs/osdep.o .libs/intl-compat.o   -L/usr/local/lib 
/usr/local/lib/libiconv.a  -O2   -Wl,-soname -Wl,libintl.so.9 -o 
.libs/libintl.so.9
/usr/bin/ld: /usr/local/lib/libiconv.a(iconv.o): relocation R_X86_64_32S 
against `a local symbol' can not be used when making a shared object; recompile 
with -fPIC
/usr/local/lib/libiconv.a: could not read symbols: Bad value

Full typescript here:
http://people.freebsd.org/~jlh/typescript.gettext.txt

-- 
Jeremie Le Hen

Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.
___
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: Troubles with dependencies (file -L is broken?)

2013-09-08 Thread Baptiste Daroussin

On Sun, Sep 08, 2013 at 12:09:32AM -0700, Maxim Sobolev wrote:
 Hi,
 
 I am trying to portupgrade my subversion and it keeps trying to install
 databases/db42 over already installed version (same version), missing the
 shared library dependency.
 
 Adding some debug into bsd.port.mk, I see:
 
 ===   subversion-1.8.3 depends on package: libtool=2.4 - found
 set -x; set -e ;  for i in libdb-4.2.so:/usr/ports/databases/db42; do
 lib=${i%%:*} ;  dir=${i#*:}  ;  target=install;  depends_args=;  echo
 -n ===   subversion-1.8.3 depends on shared library: ${lib} ;  found=0
 ;  dirs=/lib /usr/lib /usr/local/lib `/bin/cat
 /usr/local/libdata/ldconfig/* 2/dev/null || : ` ;  for libdir in $dirs;
 do  test -f ${libdir}/${lib} || continue;  if [ -x /usr/bin/file ]; then  [
 `file -b -L --mime-type ${libdir}/${lib}` = application/x-sharedlib ] ||
 continue ;  fi ;  found=1 ;  echo  - found;  done ;  if [ ${found} -eq 0
 ]; then  echo  - not found;  echo ===Verifying for $lib in $dir;
 if [ ! -d $dir ] ; then  echo = No directory for $lib.
 Skipping..;  else  if [ -n  -o -n  ]; then  subpkgfile=`(cd $dir; make
 $depends_args -V PKGFILE)`;  subpkgname=${subpkgfile%-*} ;
 subpkgname=${subpkgname##*/} ;  if [ -r ${subpkgfile} -a $target =
 install ]; then  echo ===   Installing existing package
 ${subpkgfile};  if [ -n  -a ${subpkgname} = pkg ]; then  [ -d
 /usr/ports/devel/subversion/work ] || /bin/mkdir -p
 /usr/ports/devel/subversion/work ;  /usr/bin/tar xf ${subpkgfile} -C
 /usr/ports/devel/subversion/work -s ,/.*/,,g */pkg-static ;
 /usr/ports/devel/subversion/work/pkg-static add ${subpkgfile};  /bin/rm -f
 /usr/ports/devel/subversion/work/pkg-static;  else  /usr/sbin/pkg_add
 ${subpkgfile};  fi;  elif [ -n  -a ${target} = install ]; then  echo
 ===   subversion-1.8.3 depends on package: ${subpkgfile} - not found;
 echo ===   USE_PACKAGE_DEPENDS_ONLY set - will not build from source;
 exit 1;  else  (cd $dir; make -DINSTALLS_DEPENDS $target $depends_args) ;
 fi;  else  (cd $dir; make -DINSTALLS_DEPENDS $target $depends_args) ;  fi;
 echo ===   Returning to build of subversion-1.8.3;  fi ;  fi ;  done
 + set -e
 + lib=libdb-4.2.so
 + dir=/usr/ports/databases/db42
 + target=install
 + depends_args=''
 + echo -n '===   subversion-1.8.3 depends on shared library: libdb-4.2.so'
 ===   subversion-1.8.3 depends on shared library: libdb-4.2.so+ found=0
 + /bin/cat /usr/local/libdata/ldconfig/compat7x
 /usr/local/libdata/ldconfig/mysql /usr/local/libdata/ldconfig/portupgrade
 /usr/local/libdata/ldconfig/pth
 + dirs='/lib /usr/lib /usr/local/lib /usr/local/lib/compat
 /usr/local/lib/mysql
 /usr/local/lib/compat/pkg
 /usr/local/lib/pth'
 + test -f /lib/libdb-4.2.so
 + continue
 + test -f /usr/lib/libdb-4.2.so
 + continue
 + test -f /usr/local/lib/libdb-4.2.so
 + [ -x /usr/bin/file ]
 + file -b -L --mime-type /usr/local/lib/libdb-4.2.so
 + [ inode/symlink = application/x-sharedlib ]
 + continue
 + test -f /usr/local/lib/compat/libdb-4.2.so
 + continue
 + test -f /usr/local/lib/mysql/libdb-4.2.so
 + continue
 + test -f /usr/local/lib/compat/pkg/libdb-4.2.so
 + continue
 + test -f /usr/local/lib/pth/libdb-4.2.so
 + continue
 + [ 0 -eq 0 ]
 + echo ' - not found'
  - not found
 + echo '===Verifying for libdb-4.2.so in /usr/ports/databases/db42'
 ===Verifying for libdb-4.2.so in /usr/ports/databases/db42
 
 So, file(1) call is the culprit here. Trying to reproduce in the console:
 
 [sobomax@pioneer ~]$ file -b -L --mime-type /usr/local/lib/libdb-4.2.so
 inode/symlink
 
 However:
 
 [sobomax@pioneer ~]$ hexdump -C /usr/local/lib/libdb-4.2.so | head -n 20
   7f 45 4c 46 02 01 01 09  00 00 00 00 00 00 00 00
 |.ELF|
 0010  03 00 3e 00 01 00 00 00  d0 40 02 00 00 00 00 00
 |...п@..|
 0020  40 00 00 00 00 00 00 00  b8 a6 0e 00 00 00 00 00
 |@...╦і..|
 0030  00 00 00 00 40 00 38 00  05 00 40 00 1d 00 1a 00  |@.8...@
 .|
 0040  01 00 00 00 05 00 00 00  00 00 00 00 00 00 00 00
 ||
 0050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
 ||
 0060  dc 45 0e 00 00 00 00 00  dc 45 0e 00 00 00 00 00
 |эE..эE..|
 0070  00 00 20 00 00 00 00 00  01 00 00 00 06 00 00 00  |..
 .|
 0080  00 50 0e 00 00 00 00 00  00 50 2e 00 00 00 00 00
 |.P...P..|
 0090  00 50 2e 00 00 00 00 00  fc 36 00 00 00 00 00 00
 |.P..Э6..|
 00a0  d8 3a 00 00 00 00 00 00  00 00 20 00 00 00 00 00  |ь:
 .|
 00b0  02 00 00 00 06 00 00 00  e8 54 0e 00 00 00 00 00
 |ХT..|
 00c0  e8 54 2e 00 00 00 00 00  e8 54 2e 00 00 00 00 00
 |ХT..ХT..|
 00d0  a0 01 00 00 00 00 00 00  a0 01 00 00 00 00 00 00
 |═...═...|
 00e0  08 00 00 00 00 00 00 00  50 e5 74 64 04 00 00 00
 |PЕtd|
 00f0  5c 39 0d 00 00 00 00 00  5c 39 0d 00 00 00 00 00
 |\9..\9..|
 0100  5c 39 0d 00 00 00 00 00  b4 34 00 00 00 00 00 00
 |\9..Є4..|
 0110  b4 34 00 00 00 00

Re: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous

2013-09-08 Thread Dimitry Andric

On Sep 8, 2013, at 08:14, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 On Sat, 7 Sep 2013 22:49:54 GMT
 rak...@freebsd.org wrote:
 
 Synopsis: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22:
 error: call to 'swap' is ambiguous
 
 State-Changed-From-To: open-patched
 State-Changed-By: rakuco
 State-Changed-When: Sat Sep 7 22:47:43 UTC 2013
 State-Changed-Why: 
 I don't think the previous version worked.
 
 From your description, it looks like you've switched to building with
 libc++ whereas libstdc++ was being used before.
 
 The upcoming Qt 4.8.5 plus a few patches which only made it to 4.8.6
 (but we've backported) will finally make Qt build with libc++.
 
 We've just sent an exp-run request for Qt 4.8.5, and will hopefully
 fix all these errors once it is committed.
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=181913
 
 I build the world/kernel since early this year with 
 
 CXXFLAGS+=  -stdlib=libc++
 CXXFLAGS+=  -std=c++11
 
 
 in /etc/src.conf. I do not use those flags
 in /etc/make.conf! /etc/src.conf is supposed to target ONLY
 the /usr/src world, not the ports - this is as I interpret the man page
 for /etc/src.conf and it would be logical. But this rule/thinking seems
 to be broken by some includes from /usr/ports/Mk ingredients.

Since r255321, -stdlib=libc++ is effectively the default, at least when
you haven't set gcc as the default compiler.  So it also applies to
ports, which unavoidably will lead to a bit of fallout.  My personal
experience is that most C++-based ports compile fine with libc++ instead
of libstdc++, except for a few that rely on internal libstdc++ details.

However, -std=c++11 is *not* yet the default, and C++11 has different
rules here and there, so some ports might fail to compile due to this.
For some ports, too much hacking may be required to make them work with
C++11.  So in case of trouble, try removing -std=, or setting it to
different values (c++0x, c++98, gnu++98, etc), to get the port to
compile.

Note the base system should have no problems with -std=c++11, so please
continue to use the option in src.conf, and report any problems if you
encounter them, so we can fix them. :-)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous

2013-09-08 Thread O. Hartmann

On Sun, 8 Sep 2013 14:57:01 +0200
Dimitry Andric d...@freebsd.org wrote:

 On Sep 8, 2013, at 08:14, O. Hartmann ohart...@zedat.fu-berlin.de
 wrote:
  On Sat, 7 Sep 2013 22:49:54 GMT
  rak...@freebsd.org wrote:
  
  Synopsis:
  devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error:
  call to 'swap' is ambiguous
  
  State-Changed-From-To: open-patched
  State-Changed-By: rakuco
  State-Changed-When: Sat Sep 7 22:47:43 UTC 2013
  State-Changed-Why: 
  I don't think the previous version worked.
  
  From your description, it looks like you've switched to building
  with libc++ whereas libstdc++ was being used before.
  
  The upcoming Qt 4.8.5 plus a few patches which only made it to
  4.8.6 (but we've backported) will finally make Qt build with
  libc++.
  
  We've just sent an exp-run request for Qt 4.8.5, and will hopefully
  fix all these errors once it is committed.
  
  http://www.freebsd.org/cgi/query-pr.cgi?pr=181913
  
  I build the world/kernel since early this year with 
  
  CXXFLAGS+=  -stdlib=libc++
  CXXFLAGS+=  -std=c++11
  
  
  in /etc/src.conf. I do not use those flags
  in /etc/make.conf! /etc/src.conf is supposed to target ONLY
  the /usr/src world, not the ports - this is as I interpret the man
  page for /etc/src.conf and it would be logical. But this
  rule/thinking seems to be broken by some includes
  from /usr/ports/Mk ingredients.
 
 Since r255321, -stdlib=libc++ is effectively the default, at least
 when you haven't set gcc as the default compiler.  So it also applies
 to ports, which unavoidably will lead to a bit of fallout.  My
 personal experience is that most C++-based ports compile fine with
 libc++ instead of libstdc++, except for a few that rely on internal
 libstdc++ details.
 
 However, -std=c++11 is *not* yet the default, and C++11 has different
 rules here and there, so some ports might fail to compile due to this.
 For some ports, too much hacking may be required to make them work
 with C++11.  So in case of trouble, try removing -std=, or setting it
 to different values (c++0x, c++98, gnu++98, etc), to get the port to
 compile.
 
 Note the base system should have no problems with -std=c++11, so
 please continue to use the option in src.conf, and report any
 problems if you encounter them, so we can fix them. :-)
 
 -Dimitry
 

Hello Dimitry.

I ONLY use -std=c++11 in /etc/src.conf. The base system had never
problems so far since I use it. In /etc/make.conf, I avoid it.

But, and this is obviously a logical incosistency, the ports system
includes also /etc/src.conf, and I consider /etc/src.conf as base
system only as the man page suggests.

But the discussion has already been on the list. Somewhere in the
basd.*.mk files, /etc/src.conf is included. And I guess therefore it
comes to problems. 

Oliver



signature.asc
Description: PGP signature

[QAT] r326727: 4x leftovers

2013-09-08 Thread Ports-QAT

devel/py-mongoengine: update to 0.8.4

- Update to 0.8.4
- Use zip_safe=False
- Remove leading article from COMMENT
- Take maintainership

Changes: http://docs.mongoengine.org/en/latest/changelog.html

PR: ports/181486
Submitted by:   wg (myself)
Approved by:maintainer (timeout)
-

  Build ID:  20130908135800-48145
  Job owner: w...@freebsd.org
  Buildtime: 3 hours
  Enddate:   Sun, 08 Sep 2013 17:12:53 GMT

  Revision:  r326727
  Repository:
https://svnweb.freebsd.org/ports?view=revisionrevision=326727

-

Port:devel/py-mongoengine 0.8.4

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~w...@freebsd.org/20130908135800-48145-184176/py27-mongoengine-0.8.4.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~w...@freebsd.org/20130908135800-48145-184177/py27-mongoengine-0.8.4.log

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~w...@freebsd.org/20130908135800-48145-184178/py27-mongoengine-0.8.4.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~w...@freebsd.org/20130908135800-48145-184179/py27-mongoengine-0.8.4.log


--
Buildarchive URL: https://qat.redports.org/buildarchive/20130908135800-48145
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: libiconv.a(iconv.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object

2013-09-08 Thread Jeremie Le Hen

On Sun, Sep 08, 2013 at 12:52:03PM +0200, Jeremie Le Hen wrote:
 Hi,
 
 (Please Cc: me when replying, I'm not subscribed.)
 
 I created a fresh FreeBSD 9.1-RELEASE amd64 jail.  No installed ports.
 
 I cannot build devel/gettext.  Does anyone experience the same problem?
 I invariably run into the following problem:
 
 libtool: link: cc -shared  -fPIC -DPIC  .libs/bindtextdom.o .libs/dcgettext.o 
 .libs/dgettext.o .libs/gettext.o .libs/finddomain.o .libs/hash-string.o 
 .libs/loadmsgcat.o .libs/localealias.o .libs/textdomain.o .libs/l10nflist.o 
 .libs/explodename.o .libs/dcigettext.o .libs/dcngettext.o .libs/dngettext.o 
 .libs/ngettext.o .libs/plural.o .libs/plural-exp.o .libs/localcharset.o 
 .libs/threadlib.o .libs/lock.o .libs/relocatable.o .libs/langprefs.o 
 .libs/localename.o .libs/log.o .libs/printf.o .libs/setlocale.o 
 .libs/version.o .libs/xsize.o .libs/osdep.o .libs/intl-compat.o   
 -L/usr/local/lib /usr/local/lib/libiconv.a  -O2   -Wl,-soname 
 -Wl,libintl.so.9 -o .libs/libintl.so.9
 /usr/bin/ld: /usr/local/lib/libiconv.a(iconv.o): relocation R_X86_64_32S 
 against `a local symbol' can not be used when making a shared object; 
 recompile with -fPIC
 /usr/local/lib/libiconv.a: could not read symbols: Bad value
 
 Full typescript here:
 http://people.freebsd.org/~jlh/typescript.gettext.txt

For the record, Gabor Pali pointed that inside the jail, uname(1) still
returned the version from my host (10-CURRENT), so the port makes wrong
assumptions.  This is solved using environement variables as described
in the uname(1) manpage.
 

-- 
Jeremie Le Hen

Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.
___
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] r326740: 4x leftovers

2013-09-08 Thread Ports-QAT

devel/py-mongoengine: take maintainership

- Take maintainership (forgot to do so in the last commit)

PR: ports/181486
Approved by:maintainer (timeout)
-

  Build ID:  20130908150401-39362
  Job owner: w...@freebsd.org
  Buildtime: 5 hours
  Enddate:   Sun, 08 Sep 2013 20:32:59 GMT

  Revision:  r326740
  Repository:
https://svnweb.freebsd.org/ports?view=revisionrevision=326740

-

Port:devel/py-mongoengine 0.8.4

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~w...@freebsd.org/20130908150401-39362-184400/py27-mongoengine-0.8.4.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~w...@freebsd.org/20130908150401-39362-184401/py27-mongoengine-0.8.4.log

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~w...@freebsd.org/20130908150401-39362-184402/py27-mongoengine-0.8.4.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~w...@freebsd.org/20130908150401-39362-184403/py27-mongoengine-0.8.4.log


--
Buildarchive URL: https://qat.redports.org/buildarchive/20130908150401-39362
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

2013-09-08 Thread O. Hartmann

On Fri, 06 Sep 2013 09:34:52 +0200
Guido Falsi madpi...@freebsd.org wrote:

 On 09/06/13 05:16, AN wrote:
  Hi:
 
  I am posting to both lists because this problem affects users of
  current and ports, and I didn't know which would be more
  appropriate so please forgive me.
 
  # uname -a
  FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #80 r255129: Sun
  Sep  1 16:01:36 CDT 2013
  root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL  amd64
 
  I am trying to update my ports following the entry in updating, but
  it does not seem to be working correctly.  I followed the directions
  exactly, and after 30 mins this is what has happened:
 
  # cat ports_to_update | xargs portupgrade -vf
  ---  Session started at: Thu, 05 Sep 2013 21:12:10 -0500
  [Reading data from pkg(8) ... - 890 packages found - done]
  Shared object libiconv.so.3 not found, required by httpd
  make: /usr/ports/Mk/bsd.apache.mk line 278: warning: Couldn't read
  shell's output for /usr/local/sbin/httpd -V | /usr/bin/sed -ne
  's/^Server version: Apache\/\([0-9]\)\.\([0-9]*\).*/\1\2/p'
  Shared object libiconv.so.3 not found, required by httpd
 
 This is bsd.apache.mk trying to get the apache version. but the
 apache's httpd binary cannot run because it can't find
 libiconv.so.3.
 
  apxs:Error: Sorry, no shared object support for Apache.
  apxs:Error: available under your platform. Make sure.
  apxs:Error: the Apache module mod_so is compiled into.
  apxs:Error: your server binary `/usr/local/sbin/httpd'..
  make: /usr/ports/Mk/bsd.apache.mk line 284: warning:
  /usr/local/sbin/apxs -q MPM_NAME returned non-zero status
  ** Port marked as IGNORE: www/mod_dnssd:
   is marked as broken: : Error from bsd.apache.mk. apache is
  installed (or APACHE_PORT is defined) and port requires apache22 at
  least
 
 
  Here is what I have done:
  # pkg query %ro libiconv ports_to_update
  [root@FBSD10 ~]# cat ports_to_update
 
  ...lots of output
 
  # pkg delete -f libiconv
  pkg: You are trying to delete package(s) which has dependencies
  that are still required:
  ... delete these packages anyway in forced mode
  Deinstallation has been requested for the following 1 packages:
 
   libiconv-1.14_1
 
  The deinstallation will free 2 MB
 
  Proceed with deinstalling packages [y/N]: y
  [1/1] Deleting libiconv-1.14_1...
  deleting anyway
 
done
 
  Now the update process is stuck here:
 
  ** Port marked as IGNORE: www/mod_dnssd:
   is marked as broken: : Error from bsd.apache.mk. apache is
  installed (or APACHE_PORT is defined) and port requires apache22 at
  least
 
  there are 2 ruby processes running for a long time, but nothing is
  happening to the update.
 
  43998 root520 64912K 33368K piperd  5   2:21   5.96%
  ruby19{ruby19}
  43998 root520 64912K 33368K select  1   0:00   5.96%
  ruby19{ruby19}
 
  So, it seems my system is broken now.  Did I do something wrong?
  How can the upgrade work if so many ports depend on iconv?  What
  should I do now? Should I reinstall libiconv?
 
 
 Good news is the update process did not really update anything,
 judging from the output you sent. If you just reinstall libiconv
 everything should go back to how it was, at least you get a working
 system.
 
 I admit I did not foresee this condition arising when I wrote the 
 instructions, here is a modified procedure you can follow and report 
 back about, so I can modify the UPDATING entry:
 
 # pkg query %ro libiconv ports_to_update
 # cp /usr/local/lib/libiconv.so.3 /usr/local/lib/compat/pkg/
 # ldconfig -R
 (1) # pkg delete -f libiconv
 # cat ports_to_update | xargs portupgrade -f
 
 (1) not sure if ldconfig -R is really needed, but It will not do any
  harm
 
 I added the step to preserve libiconv.so.3
 in /usr/local/lib/compat/pkg which is in the default library search
 path. In this way libiconv and it's include file shouldn't be found
 by configure scripts and the like and they should link to the system
 one, while existing binaries should keep working linking to the
 preserved one in lib/compat.
 
  Any help is appreciated.
 
 I hope this helps you, just ask for any clarifications and further
 help as needed on this matter.
 

Just for the record:

after three days of cleaning up this mess today two boxes got ready,
servers, without any GUI or fancy X11 stuff. They work.

Two other development boxes reject compiling kdelibs and stuff. After
the final update today on CURRENT r255398, ports like kdevelop,
firefox, libreoffice(!) and others crash along with virtualbox-ose-kmod
(coredump). Most of that stuff, including libreoffice, firefox was
ready last night, including kdelibs and the stuff for kdevelop. It
worked today - until now, r255398.

I do not know what happened here, but I'm through with it. Two
obviously independend processes, one from the ports side, another from
the OS side, intertwined and messy as hell rendered the systems
completely unusable. 

As I reported on several occasions, after r255259 it wasn't

Re: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous

2013-09-08 Thread O. Hartmann

On Sun, 8 Sep 2013 14:57:01 +0200
Dimitry Andric d...@freebsd.org wrote:

 On Sep 8, 2013, at 08:14, O. Hartmann ohart...@zedat.fu-berlin.de
 wrote:
  On Sat, 7 Sep 2013 22:49:54 GMT
  rak...@freebsd.org wrote:
  
  Synopsis:
  devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error:
  call to 'swap' is ambiguous
  
  State-Changed-From-To: open-patched
  State-Changed-By: rakuco
  State-Changed-When: Sat Sep 7 22:47:43 UTC 2013
  State-Changed-Why: 
  I don't think the previous version worked.
  
  From your description, it looks like you've switched to building
  with libc++ whereas libstdc++ was being used before.
  
  The upcoming Qt 4.8.5 plus a few patches which only made it to
  4.8.6 (but we've backported) will finally make Qt build with
  libc++.
  
  We've just sent an exp-run request for Qt 4.8.5, and will hopefully
  fix all these errors once it is committed.
  
  http://www.freebsd.org/cgi/query-pr.cgi?pr=181913
  
  I build the world/kernel since early this year with 
  
  CXXFLAGS+=  -stdlib=libc++
  CXXFLAGS+=  -std=c++11
  
  
  in /etc/src.conf. I do not use those flags
  in /etc/make.conf! /etc/src.conf is supposed to target ONLY
  the /usr/src world, not the ports - this is as I interpret the man
  page for /etc/src.conf and it would be logical. But this
  rule/thinking seems to be broken by some includes
  from /usr/ports/Mk ingredients.
 
 Since r255321, -stdlib=libc++ is effectively the default, at least
 when you haven't set gcc as the default compiler.  So it also applies
 to ports, which unavoidably will lead to a bit of fallout.  My
 personal experience is that most C++-based ports compile fine with
 libc++ instead of libstdc++, except for a few that rely on internal
 libstdc++ details.
 
 However, -std=c++11 is *not* yet the default, and C++11 has different
 rules here and there, so some ports might fail to compile due to this.
 For some ports, too much hacking may be required to make them work
 with C++11.  So in case of trouble, try removing -std=, or setting it
 to different values (c++0x, c++98, gnu++98, etc), to get the port to
 compile.
 
 Note the base system should have no problems with -std=c++11, so
 please continue to use the option in src.conf, and report any
 problems if you encounter them, so we can fix them. :-)
 
 -Dimitry
 
Hello Dimitry,

btw, see PR ports/181932. This is definitely NOT libc++ related.

It came up since nearly all qt4-related clients (also kdelibs) fail and
drop core on r255398 - they worked prior to the last update today.

I tried recompiling qt4- and kdelibs4 to get my kdevelop environment as
well as libreoffice back (the drop core, as well as firefox, out of the
blue).

I also tried compiling those ports without any settings of CXXFLAGS
in /etc/src.conf, but it doens't help.

I can not understand why two critical changes from different branches
of the maintainig get the same time into the public (iconv/ports and
libstdc++ vanishing). Maybe I'm wrong here, but after three days, two
nights non-stop updating I'm through with this toy.


signature.asc
Description: PGP signature

Re: x11/kdelibs4: /usr/local/include/grantlee/typeaccessor.h:70:40: error: no matching function for call to 'distance' return

2013-09-08 Thread Raphael Kubo da Costa

Raphael Kubo da Costa rak...@freebsd.org writes:

 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.

Fixed in r326778.

___
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: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous

net/openldap24-server: libtool: compile: gcc -g -O2 -Wall -DDO_SAMBA -I../../../inc [...] eval: gcc: not found *** Error code 1

Re: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous

Re: bsd.port.pre.mk vs bsd.port.options.mk

Troubles with dependencies (file -L is broken?)

Re: Troubles with dependencies (file -L is broken?)

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

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

libiconv.a(iconv.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object

Re: Troubles with dependencies (file -L is broken?)

Re: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous

Re: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous

[QAT] r326727: 4x leftovers

Re: libiconv.a(iconv.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object

[QAT] r326740: 4x leftovers

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

Re: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous

Re: x11/kdelibs4: /usr/local/include/grantlee/typeaccessor.h:70:40: error: no matching function for call to 'distance' return

18 matches

Site Navigation

Mail list logo

Footer information