Ports still using protobuf-cpp

[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-append -DGOOGLE_PROTOBUF_NO_THREADLOCAL
}

For some, like those that use qt4, (ostinato) it's more messy, because qt ignores all the normal stuff you might try to do like that.

In the end, I just added the following to 

/opt/local/include/google/protobuf/stubs/common.h

#ifndef GOOGLE_PROTOBUF_NO_THREADLOCAL
#define GOOGLE_PROTOBUF_NO_THREADLOCAL 1
#endif


and so far, that fixes all the ports for me.

But it's not a fix I'm prepared to suggest in a Portfile just yet.

Ken





On 2018-04-26, at 9:12 AM, Perry E. Metzger wrote:

> 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 from upstream (prerelease) to
> work. I need to get in touch with the maintainers.
> 
> MyPaint, et, shogun-devel, sumo: have maintainers, I haven't tested
> them yet.
> 
> raceintospace, rethinkdb: have no maintainers, have tried testing, I
> can't seem to get them to build with protobuf3-cpp. In the case of
> rethinkdb our version is ancient. In the case of raceintospace our
> version isn't that ancient.
> 
> Perry
> -- 
> Perry E. Metzger		pmetzger at macports.org