Re: Ports still using protobuf-cpp

2018-04-26 Thread Ken Cunningham
yes, fixable. mosh works with a fix. anything where you can set cpp / c / cxx flags should be fixable not qt, apparently. maybe others to be discovered :> I wonder if something in the protobuf3 headers is not better, tho. K On 2018-04-26, at 9:53 AM, Perry E. Metzger wrote: > On Thu, 26 Apr

Re: Ports still using protobuf-cpp

2018-04-26 Thread Perry E. Metzger
On Thu, 26 Apr 2018 09:18:47 -0700 Ken Cunningham wrote: > On 10.6.8, this has broken all the ports that used protobuf-cpp, as > predicted, due to the thread_local thing. Ah, I'd misinterpreted. I thought in the "mosh" discussion that you had said you now had a fix for this stuff: https://github

Re: Ports still using protobuf-cpp

2018-04-26 Thread Ken Cunningham
On 10.6.8, this has broken all the ports that used protobuf-cpp, as predicted, due to the thread_local thing. Normal ports can be fixed up by adding this (eg mosh): # force protobuf3-cpp into the no_threadlocal mode if { ${os.platform} eq "darwin" && ${os.major} < 11 } { configure.cppflags-a

Ports still using protobuf-cpp

2018-04-26 Thread Perry E. Metzger
Quick status update on the protobuf-cpp -> protobuf3-cpp work. Right now what remains to be fixed up is: MyPaint et ola raceintospace rethinkdb shogun-devel sumo (Note that in a couple of cases the dependency is indirect, via py27-protobuf.) Of these: ola: has maintainers, and needs patches fr