Date: Sun, 16 Sep 2018 07:15:13 +0000 From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 230412] graphics/GraphicsMagick: fails to build with libc++ 7 Message-ID: <bug-230412-29464-FZNV5U3XHM@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-230412-29464@https.bugs.freebsd.org/bugzilla/> References: <bug-230412-29464@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230412 Dimitry Andric <dim@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress CC| |sunpoet@FreeBSD.org --- Comment #3 from Dimitry Andric <dim@FreeBSD.org> --- (In reply to Antoine Brodin from comment #2) > Is there some progress on this issue? I've just tried "make configure" in the port, which is at r477008, and it r= an without any errors. This is with clang700-import r338690: =3D=3D=3D> Configuring for GraphicsMagick-1.3.30,1 configure: loading site script /share/dim/ports/Templates/config.site configuring GraphicsMagick 1.3.30 checking build system type... amd64-portbld-freebsd12.0 checking host system type... amd64-portbld-freebsd12.0 checking whether build environment is sane... yes checking for a BSD-compatible install... /usr/bin/install -c checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p checking for gawk... (cached) /usr/bin/awk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking for style of include used by make... GNU checking for gcc... gcc7 [...] checking whether C++ compiler is sufficient for Magick++... yes and the port compiles to the end. Maybe this is because of sunpoet's recent update to 1.3.0? Jan's example test still fails, though, but I'm not sure if it is still relevant: $ echo '#include <fstream>' | g++7 -xc++ - -std=3Dc++03 -nostdinc++ -isystem/usr/include/c++/v1 In file included from /usr/include/c++/v1/__locale:15:0, from /usr/include/c++/v1/ios:216, from /usr/include/c++/v1/ostream:138, from /usr/include/c++/v1/fstream:184, from <stdin>:1: /usr/include/c++/v1/string:811:35: error: default template arguments may no= t be used in function templates without -std=3Dc++11 or -std=3Dgnu++11 basic_string(const _CharT* __s) { ^ /usr/include/c++/v1/string:821:62: error: default template arguments may no= t be used in function templates without -std=3Dc++11 or -std=3Dgnu++11 basic_string(const _CharT* __s, const _Allocator& __a); ^ /usr/include/c++/v1/string:832:70: error: default template arguments may no= t be used in function templates without -std=3Dc++11 or -std=3Dgnu++11 basic_string(size_type __n, _CharT __c, const _Allocator& __a); ^ /usr/include/c++/v1/string:843:75: error: default template arguments may no= t be used in function templates without -std=3Dc++11 or -std=3Dgnu++11 const allocator_type& __a =3D allocator_type= ()); ^ /usr/include/c++/v1/string:847:45: error: default template arguments may no= t be used in function templates without -std=3Dc++11 or -std=3Dgnu++11 explicit basic_string(const _Tp& __t); ^ /usr/include/c++/v1/string:851:72: error: default template arguments may no= t be used in function templates without -std=3Dc++11 or -std=3Dgnu++11 explicit basic_string(const _Tp& __t, const allocator_type& __a); ^ /usr/include/c++/v1/string:874:43: error: default template arguments may no= t be used in function templates without -std=3Dc++11 or -std=3Dgnu++11 basic_string& operator=3D(const _Tp& __t) ^ This actually seems to be an issue in the <string> header, I'm checking it = with upstream now. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-230412-29464-FZNV5U3XHM>