FreeBSD ports tree https://cgit-dev.freebsd.org/ports/atom?h=2021Q2 2021-04-06T14:31:07Z 2021-04-06T14:31:07Z Mathieu Arnold mat@FreeBSD.org 2021-04-06T11:55:50Z urn:sha1:305f148f482daf30dcf728039d03d019f88344eb 2021-01-30T19:25:20Z Tobias C. Berner tcberner@FreeBSD.org 2021-01-30T19:25:20Z urn:sha1:2e36dd03b657a983c221b6a4f5fa4804060c822f - Likely there is an issue with the flavoured ports depending on an unflavoured python part though. 2020-12-28T23:02:12Z Antoine Brodin antoine@FreeBSD.org 2020-12-28T23:02:12Z urn:sha1:aa7a6c429ea62d972467d6755fa7a6f52256b452 With hat: portmgr 2020-09-21T20:29:28Z Steve Wills swills@FreeBSD.org 2020-09-21T20:29:28Z urn:sha1:ccb8e2de16bcad6ba44fd5c8d959d989a877a961 2020-07-14T12:51:40Z Steve Wills swills@FreeBSD.org 2020-07-14T12:51:40Z urn:sha1:29949b7b7cd757c6a0f764c970322368b4ccba37 2020-02-23T15:25:53Z Antoine Brodin antoine@FreeBSD.org 2020-02-23T15:25:53Z urn:sha1:41a5348a3b6a9d16a7808a76f3b3935dbdb9eb49 With hat: portmgr 2019-09-04T06:02:39Z Antoine Brodin antoine@FreeBSD.org 2019-09-04T06:02:39Z urn:sha1:4ffda9da2d377baaba47589be3e9bcf9aa8f2458 2019-09-03T19:04:09Z Steve Wills swills@FreeBSD.org 2019-09-03T19:04:09Z urn:sha1:786d08cf67b1a500780b97ad515a213c941efcc3 2019-07-26T20:46:53Z Gerald Pfeifer gerald@FreeBSD.org 2019-07-26T20:46:53Z urn:sha1:ea8c8ec7da96df12146a2cc428077258141791cf as defined in Mk/bsd.default-versions.mk which has moved from GCC 8.3 to GCC 9.1 under most circumstances now after revision 507371. This includes ports - with USE_GCC=yes or USE_GCC=any, - with USES=fortran, - using Mk/bsd.octave.mk which in turn features USES=fortran, and - with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang, c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib plus, everything INDEX-11 shows with a dependency on lang/gcc9 now. PR: 238330 2019-01-16T11:13:44Z Tijl Coosemans tijl@FreeBSD.org 2019-01-16T11:13:44Z urn:sha1:1bf487d3e73d83700f5a4aeb3a9ffbfc6e87856b a symbol matches multiple clauses the last one takes precedence. If the catch-all is last it captures everything. In the case of Qt5 libraries this caused all symbols to have a Qt_5 label while some should have Qt_5_PRIVATE_API. This only affects lld because GNU ld always gives the catch-all lowest priority. Older versions of Qt5Webengine exported some memory allocation symbols from the bundled Chromium. Version 5.9 stopped exporting these [1] but the symbols were kept as weak wrappers for the standard allocation functions to maintain binary compatibility. [2][3] The problem is that the call to the standard function in these weak wrappers is only resolved to the standard function if there's a call to this standard function in other parts of Qt5Webengine, because only then is there a non-weak symbol that takes precedence over the weak one. If there's no such non-weak symbol the call in the weak wrapper resolves to the weak wrapper itself creating an infinite call loop that overflows the stack and causes a crash. Some of the allocation functions are variants of C++ new and delete and it probably depends on the compiler whether these variants are used in other parts of Qt5Webengine. Remove the weak wrappers (make them Linux specific). This isn't binary compatible but we are already breaking that with the changes to the symbol versions. [1] https://github.com/qt/qtwebengine/commit/5c2cbfccf9aafb547b0b30914c4056abd25942a4 [2] https://github.com/qt/qtwebengine/commit/2ed5054e3a800fa97c2c9e920ba1e6ea4b6ef2a5 [3] https://github.com/qt/qtwebengine/commit/009f5ebb4bd6e50188671e0815a5dae6afe39db5 Bump all ports that depend on Qt5. PR: 234070 Exp-run by: antoine Approved by: kde (adridg)