I’ve implemented all the good suggestions for PR
https://github.com/macports/macports-ports/pull/4978 .
May we please merge this port?
> I’ve created a PR for a port of Apple’s Calendar and Contacts Server:
> https://github.com/macports/macports-ports/pull/4978
>
> May I please get some help
It's hard to even debug, but as I understand it, some objects are created by
system frameworks linked to /usr/lib/libstdc++.dylib.
The ones we create can have any linking we want them to have, but for c++11
support, we need to link them against /opt/local/lib/libgcc/libstdc++.dylib.
So
Isn't something similar to what patchelf does possible on macOs? Editing
the RPATH?
On Sun, 15 Dec 2019, 19:06 Ken Cunningham,
wrote:
> This issue is a classic c++ standard lib mixup, exactly what we have
> always feared and tried our best to avoid on MacPorts.
>
> Objects are being created
This issue is a classic c++ standard lib mixup, exactly what we have always
feared and tried our best to avoid on MacPorts.
Objects are being created using /usr/lib/libstdc++.dylib and then (in this
case) attempt to be deleted by /opt/local/lib/libstdc++.dylib and they are not
matching up, so
But shouldn't the gmp package get a revision bump now once Xcode 11.3 has
been installed on the 10.15 buildbot so that it gets built with stack
checking?
On Sun, Dec 15, 2019 at 11:31 AM Marcus Calhoun-Lopez
wrote:
> The xcode_workaround-1.0.tcl PortGroup was designed so that the workaround
>
The xcode_workaround-1.0.tcl PortGroup was designed so that the workaround is
automatically dropped when using Xcode 11.3.
-Marcus
> On Dec 15, 2019, at 8:49 AM, Jack Howarth
> wrote:
>
> FYI, the gmp test suite failure in the t-powm test case when using core2
> optimization with the
FYI, the gmp test suite failure in the t-powm test case when using core2
optimization with the default stack checking has been solved in the release
Xcode 11.3. So the current -fno-stack-checking workaround in the MacPorts
gmp package can be dropped in favor of just blacklisting Xcode 11.0 through
