Re: Apple Calendar and Contacts Server Merge Help Request for PR #4978
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 to get this PR merged? After some initial help, > including from the Apple team that developed ccs-calendarserver, this PR has > been languishing for attention for a while now. > > This is an important port because it replaces the now-defunct macOS > Server.app’s Calendar and Contacts server. > > Furthermore, there aren’t other viable open source calDAV+cardDAV server > projects that support all that ccs-calendarserver does (iMIP, APNS, etc.). > Compare to sabre/dav, inverse-inc/sogo, or Kozea/Radicale. > > I’ve had my own deployment running for over six months now, and ran > Server.app’s for years before that, and know that this is a rock solid > calDAV+cardDAV server. smime.p7s Description: S/MIME cryptographic signature
Re: gcc7/libgcc7 problems
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 patching all the system frameworks to look at /opt/local/lib/libgcc/libstdc++.dylib woulc be similar to just replacing /usr/lib/libstdc++.dylib with a new version in severity. I suppose getting libc++ working on PowerPC and using that by default is probably the best option, if we can do that. Good thing we already have done that on 10.6 and up! Sooner or later this would have happened there too... K On 2019-12-15, at 12:13 PM, Ruben Di Battista wrote: > 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 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 errors are happening. > > We've discussed this exact situation for years, but until now, it has not > happened. > > Solutions are tricky. Upstream is trying to see if they can tweak libgcc7 > 7.5.0 to not error out, like libgcc7 7.4.x did not error out. Maybe that > might work. Dunno. > > We can set the DYLD_LIBRARY_PATH to point to /opt/local/lib/libgcc/ and so > software will look there first. That works. Getting it to always apply to all > software is a bit tricky... > > You can set up a chroot environment, and run your software there -- good luck > -- if you know how to do that, you're probably not trying to run libgcc7 on a > 15 year old PowerMac. > > Or -- get ready for it -- we can update the libgcc in /usr/lib to a current > one, like the one from libgcc7 with some kind of installer that we supply > (and maintain, and and and). I can hear the groans now. > > We could, perhaps, get libc++ working on PowerMac, and use that -- it would, > naturally, have no such interaction with /usr/lib/libstdc++.dylib and > therefore problem solved. > > So -- working on it. For now, libgcc7 7.4.x is magically immune, it appears, > at least so far as we know, for now. > > K > > > On Dec 11, 2019, at 12:58, Ken Cunningham > wrote: > >> Iain has asked for a minimal reproducer and a bisected commit that generated >> the error. Then it's worth opening the bug report. >> >> I tried a few different iostream with locale test files, but so far couldn't >> repro the error. >> >> Best, >> >> Ken >> >> On Wed, Dec 11, 2019 at 12:11 PM Eric Gallager wrote: >> On 12/11/19, Ken Cunningham wrote: >> > We're having troubles with the recent gcc7 upgrade to 7.5.0 on i386 >> > (bootstrapping with non-system assembler) and on 10.5 PPC (bus errors in >> > memory handling, possibly related to locale support, maybe some other thing >> > TBA). >> > >> > We may have to bump epoch and roll back to last 7.4.x unless we can get >> > this sorted out soon, as tickets are starting up... >> > >> > Ken >> > >> >> Is there an upstream bug filed in the GCC Bugzilla about this? I >> realize the branch for 7 is closed now, but it could be due to a >> change backported from a different branch where it's also relevant...
Re: gcc7/libgcc7 problems
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 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 errors are happening. > > We've discussed this exact situation for years, but until now, it has not > happened. > > Solutions are tricky. Upstream is trying to see if they can tweak libgcc7 > 7.5.0 to not error out, like libgcc7 7.4.x did not error out. Maybe that > might work. Dunno. > > We can set the DYLD_LIBRARY_PATH to point to /opt/local/lib/libgcc/ and > so software will look there first. That works. Getting it to always apply > to all software is a bit tricky... > > You can set up a chroot environment, and run your software there -- good > luck -- if you know how to do that, you're probably not trying to run > libgcc7 on a 15 year old PowerMac. > > Or -- get ready for it -- we can update the libgcc in /usr/lib to a > current one, like the one from libgcc7 with some kind of installer that > we supply (and maintain, and and and). I can hear the groans now. > > We could, perhaps, get libc++ working on PowerMac, and use that -- it > would, naturally, have no such interaction with /usr/lib/libstdc++.dylib and > therefore problem solved. > > So -- working on it. For now, libgcc7 7.4.x is magically immune, it > appears, at least so far as we know, for now. > K > > > On Dec 11, 2019, at 12:58, Ken Cunningham > wrote: > > Iain has asked for a minimal reproducer and a bisected commit that > generated the error. Then it's worth opening the bug report. > > I tried a few different iostream with locale test files, but so far > couldn't repro the error. > > Best, > > Ken > > On Wed, Dec 11, 2019 at 12:11 PM Eric Gallager > wrote: > >> On 12/11/19, Ken Cunningham wrote: >> > We're having troubles with the recent gcc7 upgrade to 7.5.0 on i386 >> > (bootstrapping with non-system assembler) and on 10.5 PPC (bus errors in >> > memory handling, possibly related to locale support, maybe some other >> thing >> > TBA). >> > >> > We may have to bump epoch and roll back to last 7.4.x unless we can get >> > this sorted out soon, as tickets are starting up... >> > >> > Ken >> > >> >> Is there an upstream bug filed in the GCC Bugzilla about this? I >> realize the branch for 7 is closed now, but it could be due to a >> change backported from a different branch where it's also relevant... >> >
Re: gcc7/libgcc7 problems
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 errors are happening. We've discussed this exact situation for years, but until now, it has not happened. Solutions are tricky. Upstream is trying to see if they can tweak libgcc7 7.5.0 to not error out, like libgcc7 7.4.x did not error out. Maybe that might work. Dunno. We can set the DYLD_LIBRARY_PATH to point to /opt/local/lib/libgcc/ and so software will look there first. That works. Getting it to always apply to all software is a bit tricky... You can set up a chroot environment, and run your software there -- good luck -- if you know how to do that, you're probably not trying to run libgcc7 on a 15 year old PowerMac. Or -- get ready for it -- we can update the libgcc in /usr/lib to a current one, like the one from libgcc7 with some kind of installer that we supply (and maintain, and and and). I can hear the groans now. We could, perhaps, get libc++ working on PowerMac, and use that -- it would, naturally, have no such interaction with /usr/lib/libstdc++.dylib and therefore problem solved. So -- working on it. For now, libgcc7 7.4.x is magically immune, it appears, at least so far as we know, for now. K > On Dec 11, 2019, at 12:58, Ken Cunningham > wrote: > > Iain has asked for a minimal reproducer and a bisected commit that generated > the error. Then it's worth opening the bug report. > > I tried a few different iostream with locale test files, but so far couldn't > repro the error. > > Best, > > Ken > >> On Wed, Dec 11, 2019 at 12:11 PM Eric Gallager wrote: >> On 12/11/19, Ken Cunningham wrote: >> > We're having troubles with the recent gcc7 upgrade to 7.5.0 on i386 >> > (bootstrapping with non-system assembler) and on 10.5 PPC (bus errors in >> > memory handling, possibly related to locale support, maybe some other thing >> > TBA). >> > >> > We may have to bump epoch and roll back to last 7.4.x unless we can get >> > this sorted out soon, as tickets are starting up... >> > >> > Ken >> > >> >> Is there an upstream bug filed in the GCC Bugzilla about this? I >> realize the branch for 7 is closed now, but it could be due to a >> change backported from a different branch where it's also relevant...
Re: OpenBLAS fixed in Xcode 11.2
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 > 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 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 > 11.2. > > Jack > > > > On Sat, Nov 9, 2019 at 10:57 AM Marcus Calhoun-Lopez < > marcuscalhounlo...@gmail.com> wrote: > > This is an interesting idea, but there may be other factors at play. > > > > GMP has definite ideas about which compiler flags to use. > > When CFLAGS is set, GMP completely ignores its own and assumes the user > just wants what is in CFLAGS. > > > > Without CFLAGS, GMP uses, for example, -O2 -pedantic > -fomit-frame-pointer -m64 -mtune=core2 -march=core2. > > When CFLAGS is set, none of these flags are used. > > > > Following your lead, I was able to pass all of the tests just by setting > CFLAGS (*without* -fcheck-stack). > > > > -Marcus > > > > > On Nov 9, 2019, at 8:19 AM, Jack Howarth < > howarth.at.macpo...@gmail.com> wrote: > > > > > > > > > > > > On Fri, Nov 8, 2019 at 10:17 PM Ryan Schmidt > wrote: > > > On Nov 8, 2019, at 20:03, Joshua Root wrote: > > > > > > > On 2019-11-9 10:28 , Jack Howarth wrote: > > > >> I just noticed a really bizarre aspect to this Xcode 11 bug. If you > > > >> build gmp manually from source with the default compiler flags in > use... > > > >> > > > >> ./configure > > > >> make > > > >> make check > > > >> > > > >> the t-powm test case fails. However if you add -fstack-check > > > >> explicitly on CFLAGS and CXXFLAGS, the t-powm test case failure is > > > >> suppressed. > > > >> > > > >> ./configure CFLAGS='-O2 -fcheck-stack' CXXFLAGS='-O2 -fcheck-stack' > > > >> make > > > >> make check > > > > > > > > Are the default compiler flags '-O2'? > > > > > > MacPorts default optimization flag is -Os. > > > > > > > > > Same behavior... > > > > > > ./configure CFLAGS='-Os -fstack-check' CXXFLAGS='-Os -fstack-check' > > > make > > > make check > > > > > > suppresses the failure > > > > > > PASS: t-powm > > > > > > with Xcode 11.2 in a manual build. Wonder how many of the remaining > packages that are requiring -fno-check-stack could actually be 'fixed' by > explicitly passing -fcheck-stack instead. Obviously that option disabled > some of the problematic stack checking code that Apple's clang is > automatically generating in the absence of the flag. > > > > > > >
Re: OpenBLAS fixed in Xcode 11.2
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 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 11.2. > Jack > > On Sat, Nov 9, 2019 at 10:57 AM Marcus Calhoun-Lopez > wrote: > This is an interesting idea, but there may be other factors at play. > > GMP has definite ideas about which compiler flags to use. > When CFLAGS is set, GMP completely ignores its own and assumes the user just > wants what is in CFLAGS. > > Without CFLAGS, GMP uses, for example, -O2 -pedantic -fomit-frame-pointer > -m64 -mtune=core2 -march=core2. > When CFLAGS is set, none of these flags are used. > > Following your lead, I was able to pass all of the tests just by setting > CFLAGS (*without* -fcheck-stack). > > -Marcus > > > On Nov 9, 2019, at 8:19 AM, Jack Howarth > > wrote: > > > > > > > > On Fri, Nov 8, 2019 at 10:17 PM Ryan Schmidt > > wrote: > > On Nov 8, 2019, at 20:03, Joshua Root wrote: > > > > > On 2019-11-9 10:28 , Jack Howarth wrote: > > >> I just noticed a really bizarre aspect to this Xcode 11 bug. If you > > >> build gmp manually from source with the default compiler flags in use... > > >> > > >> ./configure > > >> make > > >> make check > > >> > > >> the t-powm test case fails. However if you add -fstack-check > > >> explicitly on CFLAGS and CXXFLAGS, the t-powm test case failure is > > >> suppressed. > > >> > > >> ./configure CFLAGS='-O2 -fcheck-stack' CXXFLAGS='-O2 -fcheck-stack' > > >> make > > >> make check > > > > > > Are the default compiler flags '-O2'? > > > > MacPorts default optimization flag is -Os. > > > > > > Same behavior... > > > > ./configure CFLAGS='-Os -fstack-check' CXXFLAGS='-Os -fstack-check' > > make > > make check > > > > suppresses the failure > > > > PASS: t-powm > > > > with Xcode 11.2 in a manual build. Wonder how many of the remaining > > packages that are requiring -fno-check-stack could actually be 'fixed' by > > explicitly passing -fcheck-stack instead. Obviously that option disabled > > some of the problematic stack checking code that Apple's clang is > > automatically generating in the absence of the flag. > > >
Re: OpenBLAS fixed in Xcode 11.2
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 11.2. Jack On Sat, Nov 9, 2019 at 10:57 AM Marcus Calhoun-Lopez < marcuscalhounlo...@gmail.com> wrote: > This is an interesting idea, but there may be other factors at play. > > GMP has definite ideas about which compiler flags to use. > When CFLAGS is set, GMP completely ignores its own and assumes the user > just wants what is in CFLAGS. > > Without CFLAGS, GMP uses, for example, -O2 -pedantic -fomit-frame-pointer > -m64 -mtune=core2 -march=core2. > When CFLAGS is set, none of these flags are used. > > Following your lead, I was able to pass all of the tests just by setting > CFLAGS (*without* -fcheck-stack). > > -Marcus > > > On Nov 9, 2019, at 8:19 AM, Jack Howarth > wrote: > > > > > > > > On Fri, Nov 8, 2019 at 10:17 PM Ryan Schmidt > wrote: > > On Nov 8, 2019, at 20:03, Joshua Root wrote: > > > > > On 2019-11-9 10:28 , Jack Howarth wrote: > > >> I just noticed a really bizarre aspect to this Xcode 11 bug. If you > > >> build gmp manually from source with the default compiler flags in > use... > > >> > > >> ./configure > > >> make > > >> make check > > >> > > >> the t-powm test case fails. However if you add -fstack-check > > >> explicitly on CFLAGS and CXXFLAGS, the t-powm test case failure is > > >> suppressed. > > >> > > >> ./configure CFLAGS='-O2 -fcheck-stack' CXXFLAGS='-O2 -fcheck-stack' > > >> make > > >> make check > > > > > > Are the default compiler flags '-O2'? > > > > MacPorts default optimization flag is -Os. > > > > > > Same behavior... > > > > ./configure CFLAGS='-Os -fstack-check' CXXFLAGS='-Os -fstack-check' > > make > > make check > > > > suppresses the failure > > > > PASS: t-powm > > > > with Xcode 11.2 in a manual build. Wonder how many of the remaining > packages that are requiring -fno-check-stack could actually be 'fixed' by > explicitly passing -fcheck-stack instead. Obviously that option disabled > some of the problematic stack checking code that Apple's clang is > automatically generating in the absence of the flag. > > > >
