CMakeFiles/schema_scanner.dir/schemaScanner.cc.o: In function `std::__1::basic_stringbuf<char, std::__1::char_traits<char>, std::__1::allocator<char> >::~basic_stringbuf()': /usr/include/c++/v1/sstream:189: undefined reference to `operator delete(void*, unsigned int)' CMakeFiles/schema_scanner.dir/schemaScanner.cc.o: In function `std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >::~basic_stringstream()': /usr/include/c++/v1/sstream:859: undefined reference to `operator delete(void*, unsigned int)' CMakeFiles/schema_scanner.dir/schemaScanner.cc.o: In function `std::__1::basic_filebuf<char, std::__1::char_traits<char>>::~basic_filebuf()': /usr/include/c++/v1/fstream:370: undefined reference to `operator delete(void*, unsigned int)' CMakeFiles/schema_scanner.dir/schemaScanner.cc.o: In function `std::__1::basic_ofstream<char, std::__1::char_traits<char>>::~basic_ofstream()': /usr/include/c++/v1/fstream:1142: undefined reference to `operator delete(void*, unsigned int)' collect2: error: ld returned 1 exit status http://package22.nyi.freebsd.org/data/103amd64-default-PR219275/2017-05-20_20h22m32s/logs/errors/openvsp-3.11.0_1.log http://package23.nyi.freebsd.org/data/103i386-default-PR219275/2017-05-20_20h22m29s/logs/errors/openvsp-3.11.0_1.log
I think this is related to libc++. On my system (11.0-RELEASE), vsp is linked against libc++: ldd /usr/local/bin/vsp /usr/local/bin/vsp: libcpptest.so.0 => /usr/local/lib/libcpptest.so.0 (0x8010fb000) libxml2.so.2 => /usr/local/lib/libxml2.so.2 (0x80130e000) libfltk_images.so.1.3 => /usr/local/lib/libfltk_images.so.1.3 (0x8016a4000) libfltk_forms.so.1.3 => /usr/local/lib/libfltk_forms.so.1.3 (0x8018b1000) libfltk_gl.so.1.3 => /usr/local/lib/libfltk_gl.so.1.3 (0x801ab8000) libGL.so.1 => /usr/local/lib/libGL.so.1 (0x801cd4000) libfltk.so.1.3 => /usr/local/lib/libfltk.so.1.3 (0x801f5d000) libSM.so.6 => /usr/local/lib/libSM.so.6 (0x80225f000) libICE.so.6 => /usr/local/lib/libICE.so.6 (0x802466000) libX11.so.6 => /usr/local/lib/libX11.so.6 (0x802681000) libXext.so.6 => /usr/local/lib/libXext.so.6 (0x8029c0000) libGLU.so.1 => /usr/local/lib/libGLU.so.1 (0x802bd1000) libGLEW.so.1 => /usr/local/lib/libGLEW.so.1 (0x802e59000) libthr.so.3 => /lib/libthr.so.3 (0x803116000) libc++.so.1 => /usr/lib/libc++.so.1 (0x80333d000) <------ libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x8035fc000) libm.so.5 => /lib/libm.so.5 (0x80381a000) libgcc_s.so.1 => /usr/local/lib/gcc5/libgcc_s.so.1 (0x803a45000) libc.so.7 => /lib/libc.so.7 (0x803c5b000) libz.so.6 => /lib/libz.so.6 (0x80400f000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x804226000) libXcursor.so.1 => /usr/local/lib/libXcursor.so.1 (0x80444f000) libXfixes.so.3 => /usr/local/lib/libXfixes.so.3 (0x80465a000) libXft.so.2 => /usr/local/lib/libXft.so.2 (0x80485f000) libfontconfig.so.1 => /usr/local/lib/libfontconfig.so.1 (0x804a75000) libXinerama.so.1 => /usr/local/lib/libXinerama.so.1 (0x804cbb000) libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x804ebd000) libjpeg.so.8 => /usr/local/lib/libjpeg.so.8 (0x8050f7000) libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x805365000) libxcb-dri3.so.0 => /usr/local/lib/libxcb-dri3.so.0 (0x80558c000) libxcb-present.so.0 => /usr/local/lib/libxcb-present.so.0 (0x80578e000) libxcb-sync.so.1 => /usr/local/lib/libxcb-sync.so.1 (0x805990000) libxshmfence.so.1 => /usr/local/lib/libxshmfence.so.1 (0x805b96000) libglapi.so.0 => /usr/local/lib/libglapi.so.0 (0x805d97000) libXdamage.so.1 => /usr/local/lib/libXdamage.so.1 (0x805feb000) libX11-xcb.so.1 => /usr/local/lib/libX11-xcb.so.1 (0x8061ed000) libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0x8063ee000) libxcb-glx.so.0 => /usr/local/lib/libxcb-glx.so.0 (0x806614000) libxcb-dri2.so.0 => /usr/local/lib/libxcb-dri2.so.0 (0x80682d000) libXxf86vm.so.1 => /usr/local/lib/libXxf86vm.so.1 (0x806a31000) libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x806c35000) libXrender.so.1 => /usr/local/lib/libXrender.so.1 (0x806e45000) libfreetype.so.6 => /usr/local/lib/libfreetype.so.6 (0x80704e000) libXau.so.6 => /usr/local/lib/libXau.so.6 (0x8072f6000) libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x8074f8000) libbz2.so.4 => /usr/lib/libbz2.so.4 (0x8076fd000) But in 10.x the libc++ does not provide a delete operator with parameters (void*, unsigned long). Just these ones[1]: _LIBCPP_WEAK _LIBCPP_NEW_DELETE_VIS 120 void 121 operator delete(void* ptr) _NOEXCEPT 122 { 123 if (ptr) 124 ::free(ptr); 125 } 126 127 _LIBCPP_WEAK _LIBCPP_NEW_DELETE_VIS 128 void 129 operator delete(void* ptr, const std::nothrow_t&) _NOEXCEPT 130 { 131 ::operator delete(ptr); 132 } 133 134 _LIBCPP_WEAK _LIBCPP_NEW_DELETE_VIS 135 void 136 operator delete[] (void* ptr) _NOEXCEPT 137 { 138 ::operator delete (ptr); 139 } 140 141 _LIBCPP_WEAK _LIBCPP_NEW_DELETE_VIS 142 void 143 operator delete[] (void* ptr, const std::nothrow_t&) _NOEXCEPT 144 { 145 ::operator delete[](ptr); 146 } 147 148 #endif // !__GLIBCXX__ However, in 11.x, we have these operators: $ egrep '^operator delete' /usr/src/contrib/libc++/src/new.cpp operator delete(void* ptr) _NOEXCEPT operator delete(void* ptr, const std::nothrow_t&) _NOEXCEPT operator delete(void* ptr, size_t) _NOEXCEPT <--- operator delete[] (void* ptr) _NOEXCEPT operator delete[] (void* ptr, const std::nothrow_t&) _NOEXCEPT operator delete[] (void* ptr, size_t) _NOEXCEPT I think this is the same problem that affects other ports[2]. I suppose either updating libc++ on 10.x or forcing linking against libstc++ if possible should help. [1] https://svnweb.freebsd.org/base/release/10.3.0/contrib/libc%2B%2B/src/new.cpp?revision=297553&view=markup [2] https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=fails%20to%20build%20with%20lang%2Fgcc6%20or%20later%20on%2010.*&list_id=175765
(In reply to fernando.apesteguia from comment #1) > ldd /usr/local/bin/vsp "ldd -a" exposes more libc++ consumers: libGLU (from mesa-libs), fltk and cpptest. Each of those libraries may have their own consumers (ignoring openvsp) linked against libc++. > But in 10.x the libc++ does not provide a delete operator with parameters (void*, unsigned long). [...] > operator delete(void* ptr, size_t) _NOEXCEPT <--- > operator delete[] (void* ptr, size_t) _NOEXCEPT Probably added by https://llvm.org/viewvc/llvm-project?view=revision&revision=229281 > either updating libc++ on 10.x or forcing linking against libstc++ if possible should help. Can toolchain@ suggest a better workaround? libstdc++ usage is fragile as any dependency can bring libc++ into runtime leading to crashes. While mixing libc++ and libstdc++ is possible by replacing libsupc++ with libcxxrt it's not supported by any of lang/gcc* ports. libcxxrt is essentially frozen from ports POV. Alternatives are locking the ports to USE_GCC < 6 (if gerald is OK) or laying on BROKEN_FreeBSD_10 deathbed.
It should be no problem to merge libc++ r229281 into stable/10. But that doesn't magically make old 10.x releases work...
(In reply to Jan Beich from comment #2) > Alternatives are locking the ports to USE_GCC < 6 (if gerald is OK) > or laying on BROKEN_FreeBSD_10 deathbed. I prefer the latter, though the former is also fine if preferred (and may be more user friendly).
I'll merge libc++ r229281 into stable/10 later today, at least it'll appear in 10.4-RELEASE then. Jan, is it worth bumping __FreeBSD_version for this?
A commit references this bug: Author: dim Date: Wed Jul 19 18:22:32 UTC 2017 New revision: 321222 URL: https://svnweb.freebsd.org/changeset/base/321222 Log: Pull in r229281 from upstream libc++ (by Larisse Voufo): Implement C++14's sized deallocation functions, since there are no longer implicitly defined by clang, as of r229241. This allows ports which use C++14's sized deallocation functions, such as cad/openvsp, to build on stable/10. Bump __FreeBSD_version to allow detection from ports. Direct commit, since stable/11 and head already have newer versions of libc++ which include this change. PR: 219484 Changes: stable/10/contrib/libc++/include/new stable/10/contrib/libc++/src/new.cpp stable/10/sys/sys/param.h
openvsp builds fine with lang/gcc6 on /stable/10@321237
(In reply to Jan Beich from comment #7) Thanks for testing. I wonder, how ofter are snapshots of -STABLE created? I couldn't find any new enough to test the port with poudriere: http://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/10.3-STABLE/
Does this PR need additional action on my side in order to be closed?
(In reply to fernando.apesteguia from comment #9) > Does this PR need additional action on my side in order to be closed? Good point, based on this being fixed in the base (no change to your port required), let me close this. Thanks to dim!
Is a workaround for the port not possible or not required in the meantime? If not, can it marked BROKEN with GCC > X, limited to certain GCC versions, or similar? Doubtful, but if there's absolutely nothing else to do here, the issue should be reclassified to Base System -> something, so that the the commit to stable10 can be documented (mfc flags dont exist for ports issues) and assigned to dim@ as the resolving developer
(In reply to Kubilay Kocak from comment #11) Having a look at the error log, it seems the missing operator is used in libc++ itself (~basic_stringbug()). With GCC < 6, the compiler provides the builtin delete operators, but if they are missing, is the code included from libc++ which fails to link. I don't think a workaround is possible (at least without being extremely hackish). The port doesn't need GCC 6. It could be restricted to GCC < 6 or pinned down to GCC 5 (all of this conditionally if FreeBSD < 11). I would not mark it as BROKEN unless absolutely necessary.
Thank you Fernando If someone™ (ideally maintainer) could add a patch which limits which version of GCC is selected/used for affected FreeBSD versions, that would be great
(In reply to Kubilay Kocak from comment #13) Will do. Can anyone in the meantime commit this other PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220951 It's a pending update to 3.13.0. I would like to make the changes on top of that. Thanks
Created attachment 184778 [details] patch to the ports tree Patch to force GCC 5 in FreeBSD < 11
Comment on attachment 184778 [details] patch to the ports tree Is this patch acceptable?
(In reply to fernando.apesteguia from comment #16) >> Is this patch acceptable? > > .if ${OSVERSION} < 1100000 Note that you generally want to choose a more specific version that corresponds more closely to the commit that imported the libc++ version with the new overloads. In any case, I think you can simplify the patch by just setting USE_CXXSTD=gnu++11 -- GCC 6 builds with -std=gnu++14 by default, and the new overloads were added in C++14. Since you only need C++11 to build the code you can use an older standard. I've done that here and the port built fine on 10.3-i386 with GCC 6.
(In reply to Raphael Kubo da Costa from comment #17) Thanks for the hint. Reworking patch and running builds in poudriere...
Created attachment 184812 [details] patch to the ports tree New simplified patch as suggested by rakuco@. Bumping PORTREVISION. Q/A: - portlint -AC: OK - poudriere ports for {10.3,11.0}{amd64,i386}: OK
A commit references this bug: Author: rakuco Date: Fri Jul 28 21:45:45 UTC 2017 New revision: 446855 URL: https://svnweb.freebsd.org/changeset/ports/446855 Log: Explicitly build with -std=gnu++11. This fixes the build with GCC 6, which switched its default from -std=gnu++98 to -std=gnu++14. With this switch, it added a `operator delete(void*, size_t)' overload and uses it for all delete calls. This does not play well with dependencies built with other compilers (such as base clang), which use the old operator delete overload and cause linking errors. PR: 219484 Submitted by: fernando.apesteguia@gmail.com (maintainer) MFH: 2017Q3 Changes: head/cad/openvsp/Makefile
Committed, thank you. I've left out the PORTREVISION bump because the generated code should remain the same (C++11 was being used before by working compilers, and GCC 6 was just broken).
Re-open pending MFH. Please set merge-quarterly to + if/when done
Since the update to GGC 6 is never going to hit the quarterly branch (and hardly going to land on trunk if dependent bugs keep being re-opened <ahem>), I do not see a need to backport this kind of change. Nothing is broken in quarterly here.
A commit references this bug: Author: feld Date: Thu Aug 3 15:13:32 UTC 2017 New revision: 447224 URL: https://svnweb.freebsd.org/changeset/ports/447224 Log: MFH: r446855 Explicitly build with -std=gnu++11. This fixes the build with GCC 6, which switched its default from -std=gnu++98 to -std=gnu++14. With this switch, it added a `operator delete(void*, size_t)' overload and uses it for all delete calls. This does not play well with dependencies built with other compilers (such as base clang), which use the old operator delete overload and cause linking errors. PR: 219484 Submitted by: fernando.apesteguia@gmail.com (maintainer) Approved by: ports-secteam (with hat) Changes: _U branches/2017Q3/ branches/2017Q3/cad/openvsp/Makefile