Re: [kde-freebsd] ports/181932: www/qt4-webkit: fatal error: 'ext/atomicity.h' file not found (on CLANG only)
Synopsis: www/qt4-webkit: fatal error: 'ext/atomicity.h' file not found (on CLANG only) State-Changed-From-To: open->closed State-Changed-By: rakuco State-Changed-When: Mon Sep 9 08:38:29 UTC 2013 State-Changed-Why: Fixed. http://www.freebsd.org/cgi/query-pr.cgi?pr=181932 ___ 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/181935: x11/libkonq: ERROR: cmake/modules/FindKDE4Internal.cmake not found in Call Stack (most recent call first): CMakeLists.txt:12 (find_package)
The following reply was made to PR ports/181935; it has been noted by GNATS. From: "O. Hartmann" To: Raphael Kubo da Costa Cc: bug-follo...@freebsd.org Subject: Re: ports/181935: x11/libkonq: ERROR: cmake/modules/FindKDE4Internal.cmake not found in Call Stack (most recent call first): CMakeLists.txt:12 (find_package) Date: Sun, 8 Sep 2013 22:26:56 +0200 --Sig_/eC3cI1yfwNMRQTAo+w5+4iO Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 08 Sep 2013 21:54:29 +0300 Raphael Kubo da Costa wrote: > Has x11/kdelibs4 been installed correctly? Yes. I was able to update (iconv matter, see UPDATING 20130904) kdelibs in queue as the build process suggested automatically with CURRENT r255253. On CURRENT r255398, it is not possible to build port kdelibs4 on all CURENT boxes which has undergome the update process. Mor scaring and frustrating, with CURRENT r255398 several ports, including kdevelop, libreoffice, firefox do not work anymore and dumps core! The worked AFTER the successful update and BEFORE the last OS update to r255398, as far as I can recall r255363. --Sig_/eC3cI1yfwNMRQTAo+w5+4iO Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSLN2XAAoJEOgBcD7A/5N8VpkH/Rx/J0dg2IkXfV8iiNpXxy9c wh3cwf5nkdTUpYvtamPHjaN9xyEfB/xe64u/UK5YEG6+F6siHpF3MaGiyTOMtjkK OyXe5/72NImyiv2f3ub8m7XhXzur6BjB9ZDTUD8oYwVr+DyIWdKTwtLdNQMu4DHf nPt7HxvNuruESzT4DxNja40ujTXm5UeEXks7eKXTjvYPbOHgAHex6QG/BrlvsRO6 3JaLHoVk3T/JK38xltPTj8QVMMXTCqobdPI/tdoucoOnyrM70r2NZ785fg/E/lJY WGurpogFxhby+o4SJnrSIhy5MFPJp+/oJSgZwhBv5zgDfDAPevJeFbbCyjCcP4k= =xQAX -END PGP SIGNATURE- --Sig_/eC3cI1yfwNMRQTAo+w5+4iO-- ___ 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 wrote: > On Sep 8, 2013, at 08:14, O. Hartmann > 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
[kde-freebsd] Current problem reports assigned to k...@freebsd.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o ports/181952 kdedevel/kdevelop-kde4: CMake Error at /usr/local/share/c o ports/181935 kdex11/libkonq: ERROR: cmake/modules/FindKDE4Internal.cma o ports/181764 kdex11/kdelibs4 missing dependencies o ports/181335 kde[PATCH] devel/qmake4: Fix port test and Tinderbox, tri o ports/181212 kde[patch] textproc/redland: add ftp/curl dependency o ports/181210 kde[patch] textproc/rasqal: add ftp/curl dependency o ports/181164 kdex11/pimkde4 not bild o ports/181163 kdex11/kde4 not working Drag and drop. o ports/181141 kdedevel/qt4-designer: installation of files with hardcod o ports/180996 kdedevel/qt4-designer: /usr/local/lib/qt4/libphonon.so: c o ports/180927 kdebuild of x11-themes/kde4-wallpapers-freebsd fails o ports/180926 kdepackage creation fails for sysutils/k3b-kde4 o ports/180713 kdeports/devel/xsd fails to compile due to missing depend o ports/180674 kdemath/cantor: configure does not detect R, but R is ins o ports/180632 kdeKDE4 + QT4 shall have an option to compile with debug p ports/180615 kde[PATCH] devel/qtcreator: update to 2.8.0 o ports/180467 kde[partial patch] Make devel/py-qt4-core work with pytho o ports/180434 kde[ports] multimedia/phonon: ia64: /usr/local/lib/libqze o ports/179202 kdex11/kde4-workspace (and elsewhere): automoc4 SEGVs on o ports/178063 kde[Patch] graphics/digikam-kde4 can't edit images s ports/177479 kdedevel/py-pykde4 doesn't saves port options o ports/177059 kdedevel/cmake: /usr/share/cmake/Modules/FindLibXml2.cmak o ports/177018 kdeCan't build devel/xsd o ports/176901 kde[bsd.cmake.mk] disable rpath removal o ports/176869 kdex11/kde4: klauncher crash while attaching virtual cdro o ports/176862 kde[request] x11/kde4: supply debug libs for KDE binary p s ports/176804 kdedevel/qt4-corelib 313633 does not build on 9-STABLE o ports/174728 kdeLet textproc/soprano know about different odbc f ports/173771 kdeCONFLICTS_BUILD for deskutils/superkaramba s ports/173770 kdeCorrect CONFLICTS_BUILD for editors/calligra f ports/172359 kde[PATCH] editors/calligra: Fix build with clang++ -stdl f ports/169671 kdeeditors/calligra Spreadsheet throws and exception on e f ports/165642 kdex11/kde4: keeps locking the screen. o ports/165213 kdedevel/cmake: Reinplacement of paths in Modules is bad o ports/156901 kde[patch] devel/cmake breaks with CC containing spaces f ports/151154 kdeaudio/amarok-kde4 crashes on network activity if ports 36 problems total. ___ 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 wrote: > On Sep 8, 2013, at 08:14, O. Hartmann > 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::vector 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/*: > > If those ports .include 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/*: > > > > > > If those ports .include 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 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/181935: x11/libkonq: ERROR: cmake/modules/FindKDE4Internal.cmake not found in Call Stack (most recent call first): CMakeLists.txt:12 (find_package)
The following reply was made to PR ports/181935; it has been noted by GNATS. From: Raphael Kubo da Costa To: "O. Hartmann" Cc: bug-follo...@freebsd.org Subject: Re: ports/181935: x11/libkonq: ERROR: cmake/modules/FindKDE4Internal.cmake not found in Call Stack (most recent call first): CMakeLists.txt:12 (find_package) Date: Mon, 09 Sep 2013 18:39:40 +0300 "O. Hartmann" writes: > On Sun, 08 Sep 2013 21:54:29 +0300 > Raphael Kubo da Costa wrote: > >> Has x11/kdelibs4 been installed correctly? > > Yes. I was able to update (iconv matter, see UPDATING 20130904) kdelibs > in queue as the build process suggested automatically with CURRENT > r255253. > > On CURRENT r255398, it is not possible to build port kdelibs4 on all > CURENT boxes which has undergome the update process. > > Mor scaring and frustrating, with CURRENT r255398 several ports, > including kdevelop, libreoffice, firefox do not work anymore and dumps > core! The worked AFTER the successful update and BEFORE the last OS > update to r255398, as far as I can recall r255363. Can you try again after rebuilding qt4-corelib and kdelibs4 (with ports after r326778)? ___ 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
