[Bug 219484] cad/openvsp: fails to build with lang/gcc6 or later on 10.*

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Sun Jun 11 18:21:22 UTC 2017


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219484

--- Comment #1 from fernando.apesteguia at gmail.com ---
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

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-ports-bugs mailing list