Bug 219484 - cad/openvsp: Fails to build with lang/gcc6 or later on 10.3 (< 11.0)
Summary: cad/openvsp: Fails to build with lang/gcc6 or later on 10.3 (< 11.0)
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Raphael Kubo da Costa
URL:
Keywords:
Depends on: 220951
Blocks: 219275
  Show dependency treegraph
 
Reported: 2017-05-24 03:40 UTC by Jan Beich
Modified: 2017-08-05 05:33 UTC (History)
6 users (show)

See Also:
gerald: maintainer-feedback+
koobs: merge-quarterly+


Attachments
patch to the ports tree (918 bytes, patch)
2017-07-27 21:04 UTC, Fernando Apesteguía
fernape: maintainer-approval+
Details | Diff
patch to the ports tree (888 bytes, patch)
2017-07-28 21:05 UTC, Fernando Apesteguía
fernape: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer 2017-05-24 03:40:18 UTC
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
Comment 1 Fernando Apesteguía freebsd_committer 2017-06-11 18:21:22 UTC
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
Comment 2 Jan Beich freebsd_committer 2017-07-16 22:45:17 UTC
(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.
Comment 3 Dimitry Andric freebsd_committer 2017-07-17 06:53:07 UTC
It should be no problem to merge libc++ r229281 into stable/10.  But that doesn't magically make old 10.x releases work...
Comment 4 Gerald Pfeifer freebsd_committer 2017-07-19 07:03:37 UTC
(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).
Comment 5 Dimitry Andric freebsd_committer 2017-07-19 10:54:09 UTC
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?
Comment 6 commit-hook freebsd_committer 2017-07-19 18:22:38 UTC
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
Comment 7 Jan Beich freebsd_committer 2017-07-20 06:32:47 UTC
openvsp builds fine with lang/gcc6 on /stable/10@321237
Comment 8 Fernando Apesteguía freebsd_committer 2017-07-20 16:01:26 UTC
(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/
Comment 9 Fernando Apesteguía freebsd_committer 2017-07-24 15:09:12 UTC
Does this PR need additional action on my side in order to be closed?
Comment 10 Gerald Pfeifer freebsd_committer 2017-07-24 15:33:24 UTC
(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!
Comment 11 Kubilay Kocak freebsd_committer freebsd_triage 2017-07-25 04:17:08 UTC
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
Comment 12 Fernando Apesteguía freebsd_committer 2017-07-25 21:27:16 UTC
(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.
Comment 13 Kubilay Kocak freebsd_committer freebsd_triage 2017-07-26 02:39:02 UTC
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
Comment 14 Fernando Apesteguía freebsd_committer 2017-07-26 15:23:39 UTC
(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
Comment 15 Fernando Apesteguía freebsd_committer 2017-07-27 21:04:24 UTC
Created attachment 184778 [details]
patch to the ports tree

Patch to force GCC 5 in FreeBSD < 11
Comment 16 Fernando Apesteguía freebsd_committer 2017-07-27 21:05:34 UTC
Comment on attachment 184778 [details]
patch to the ports tree

Is this patch acceptable?
Comment 17 Raphael Kubo da Costa freebsd_committer 2017-07-28 12:05:32 UTC
(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.
Comment 18 Fernando Apesteguía freebsd_committer 2017-07-28 16:45:27 UTC
(In reply to Raphael Kubo da Costa from comment #17)

Thanks for the hint.

Reworking patch and running builds in poudriere...
Comment 19 Fernando Apesteguía freebsd_committer 2017-07-28 21:05:04 UTC
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
Comment 20 commit-hook freebsd_committer 2017-07-28 21:45:54 UTC
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
Comment 21 Raphael Kubo da Costa freebsd_committer 2017-07-28 21:48:31 UTC
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).
Comment 22 Kubilay Kocak freebsd_committer freebsd_triage 2017-07-29 07:35:12 UTC
Re-open pending MFH. Please set merge-quarterly to + if/when done
Comment 23 Gerald Pfeifer freebsd_committer 2017-07-29 08:19:49 UTC
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.
Comment 24 commit-hook freebsd_committer 2017-08-03 15:14:05 UTC
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