Re: [kde-freebsd] ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
Am 08.09.2013 08:14, schrieb 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. There are ports that use bsd.prog.mk instead of the Makefile supplied with the source files. Just grep for bsd.port.mk in the port's files sub directory, if you find that /etc/src.conf settings affect a port. I think these ports are in violation of POLA and had a longer mail exchange with a port maintainer, who told me that use of bsd.prog.mk was the preferred method to build binaries on FreeBSD, for base and for ports. So no file under /usr/ports/Mk is to blame, but some ports do implicitly reference /etc/src.conf via their use of bsd.prog.mk. Regards, STefan NB: I just performed the grep suggested above and found that the following ports mention bsd.prog.mk in files/*: archivers/parchive archivers/pixz archivers/zipmix audio/id3v2 audio/mp3gain benchmarks/raidtest comms/mlan comms/mlan3 comms/obexapp converters/chmview converters/iconv devel/bcc devel/calibrator devel/frink devel/libpasori devel/linux_kdump devel/opencvs devel/qmake devel/qmake4 devel/ruby-byaccr dns/dnsreflector editors/fb editors/hexpert editors/tamago editors/tweak emulators/cpmtools finance/libstocks ftp/bsdftpd-ssl ftp/ftpsesame games/cre games/xroach graphics/exiftran graphics/s10sh japanese/edyvalue japanese/kon2-16dot japanese/man japanese/suicavalue mail/althea mail/archivesmtp mail/biffer mail/dma math/moo misc/cpuid misc/team net-mgmt/choparp net-mgmt/icmpquery net-mgmt/ipv6mon net/ifdepd net/openntpd net/packetdrill net/pcnfsd net/pppd23 net/pxe-pdhcp net/sharity-light net/skyfish palm/mdbconv print/epsonepl print/mup security/ipv6toolkit security/isakmpd security/openssh-askpass security/sst shells/nologinmsg shells/v7sh sysutils/bsdmoted sysutils/freqsdwn sysutils/jfbterm sysutils/sb16config sysutils/sbniconfig sysutils/setquota textproc/hhm textproc/wordnet www/http_get www/http_load www/http_post www/mathopd www/mohawk x11-wm/vtwm x11/gpctool x11/wmxss ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
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 ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
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. :-) I've been using clang and libc++ successfully on 9.1-RELEASE for quite some time now. Based on what I've learned, expect the following pitfalls that might hit you hard in production: - Bugs in in libc++: CURRENT is good about pulling in fixes, but there are still quite basic things getting fixed, e.g. cout/cerr not being thread safe (this was supposedly fixed in CURRENT and STABLE just a few weeks ago). Another example was handling std::vectorbool incorrectly (ouch). Other problems only affect C++11/C++14 features and shouldn't be a big issue when porting. - Mixed C++ library linkage: For some ports autoconf/libtool might pull in libstdc++ by accident, you really don't want this to happen since std types don't match (e.g. std::exception and everything inheriting from it, which will break exception handling in client code). - Incompatibilities in corner cases of the language: A good example is the exception specification of destructors. Those are defaulting to noexcept(true) now, while in C++03 it's the opposite. Even though it's bad design in almost all cases, the language permits throwing from destructors in general. I got hit by that when porting devel/ice, which depends on databases/db5, which has no exception specification for destructors, but throws from them under certain circumstances (e.g. database close failed), in that specific case also from callbacks that were called from within db5. Overall the code was quite convoluted, but valid C++03. On top of that there are the usual incompatibilities between implementations (like iostreams in gcc 4.2's libstdc++ does some things differently then the imho more compliant libc++) and compile time problems (like the swap issue you experiences, those are easy to fix). So the bottom line is: When converting a port to use clang++ -std=c++11 -stdlib=libc++, the fact that it builds ok and runs a couple of unit tests without problems is not enough. Cheers, Michael -- Michael Gmelin ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
On Mon, 2013-09-09 at 08:57 +0200, Stefan Esser wrote: Am 08.09.2013 08:14, schrieb 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. There are ports that use bsd.prog.mk instead of the Makefile supplied with the source files. Just grep for bsd.port.mk in the port's files sub directory, if you find that /etc/src.conf settings affect a port. I think these ports are in violation of POLA and had a longer mail exchange with a port maintainer, who told me that use of bsd.prog.mk was the preferred method to build binaries on FreeBSD, for base and for ports. So no file under /usr/ports/Mk is to blame, but some ports do implicitly reference /etc/src.conf via their use of bsd.prog.mk. Regards, STefan NB: I just performed the grep suggested above and found that the following ports mention bsd.prog.mk in files/*: list snipped If those ports .include bsd.port.mk before bsd.prog.mk, I think everything should work properly. It looks like src.conf is an opt-out system, and bsd.port.mk sets the variable to opt out. I don't especially like this (opt-in would be better), but I don't see an easy fix either. We use bsd.prog.mk at $work (I'd better go add the opt-out now), it seems like others probably do the same. It would be much better if the base build opted in, but the only way I can see to do that would be to install a makefile.up system where a makefile.up in every directory under the base src allows walking up to the top of the src hierarchy no matter where the build is started from, so that you can always get some top-level file to do the opt-in. -- Ian ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
On Mon, 2013-09-09 at 07:51 -0600, Ian Lepore wrote: On Mon, 2013-09-09 at 08:57 +0200, Stefan Esser wrote: Am 08.09.2013 08:14, schrieb 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. There are ports that use bsd.prog.mk instead of the Makefile supplied with the source files. Just grep for bsd.port.mk in the port's files sub directory, if you find that /etc/src.conf settings affect a port. I think these ports are in violation of POLA and had a longer mail exchange with a port maintainer, who told me that use of bsd.prog.mk was the preferred method to build binaries on FreeBSD, for base and for ports. So no file under /usr/ports/Mk is to blame, but some ports do implicitly reference /etc/src.conf via their use of bsd.prog.mk. Regards, STefan NB: I just performed the grep suggested above and found that the following ports mention bsd.prog.mk in files/*: list snipped If those ports .include bsd.port.mk before bsd.prog.mk, I think everything should work properly. It looks like src.conf is an opt-out system, and bsd.port.mk sets the variable to opt out. I don't especially like this (opt-in would be better), but I don't see an easy fix either. We use bsd.prog.mk at $work (I'd better go add the opt-out now), it seems like others probably do the same. It would be much better if the base build opted in, but the only way I can see to do that would be to install a makefile.up system where a makefile.up in every directory under the base src allows walking up to the top of the src hierarchy no matter where the build is started from, so that you can always get some top-level file to do the opt-in. Hrm. I take that back. You can't set _WITHOUT_SRCCONF and then .include bsd.prog.mk and expect anything to work. For some reason all the setting of the MK_whatever knobs is disabled by setting _WITHOUT_SRCCONF, and without all those things defined, the rest of the bsd.*.mk files don't work. ::sigh:: What a mess. -- Ian ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
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 ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
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 ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
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 ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
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 ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
Synopsis: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous State-Changed-From-To: patched-closed State-Changed-By: rakuco State-Changed-When: Mon Sep 9 00:48:20 UTC 2013 State-Changed-Why: In the end I didn't wait for the exp-run, otherwise Qt and the world would be broken. Fixed in r326562 and r326688. http://www.freebsd.org/cgi/query-pr.cgi?pr=181913 ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
Synopsis: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous Responsible-Changed-From-To: freebsd-ports-bugs-kde Responsible-Changed-By: edwin Responsible-Changed-When: Sat Sep 7 13:40:08 UTC 2013 Responsible-Changed-Why: Over to maintainer (via the GNATS Auto Assign Tool) http://www.freebsd.org/cgi/query-pr.cgi?pr=181913 ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
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 ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
