protobuf-3.0.0-beta-1 compilation error on OpenBSD 5.8 release compiler [solved/workaround]

[eau-u4f]

$ gmake
gmake all-recursive
gmake[1]: Entering directory '/home/rival/Downloads/protobuf-3.0.0-beta-1'
Making all in .
gmake[2]: Entering directory '/home/rival/Downloads/protobuf-3.0.0-beta-1'
gmake[2]: Leaving directory '/home/rival/Downloads/protobuf-3.0.0-beta-1'
Making all in src
gmake[2]: Entering directory '/home/rival/Downloads/protobuf-3.0.0-beta-1/src'
depbase=echo google/protobuf/arena.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||';
/bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -pthread -DHAVE_PTHREAD=1 -DHAVE_ZLIB=1 -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -O2 -g -DNDEBUG -MT google/protobuf/arena.lo -MD -MP -MF $depbase.Tpo -c -o google/protobuf/arena.lo google/protobuf/arena.cc &&
mv -f $depbase.Tpo $depbase.Plo
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -pthread -DHAVE_PTHREAD=1 -DHAVE_ZLIB=1 -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -O2 -g -DNDEBUG -MT google/protobuf/arena.lo -MD -MP -MF google/protobuf/.deps/arena.Tpo -c google/protobuf/arena.cc -fPIC -DPIC -o google/protobuf/.libs/arena.o
In file included from google/protobuf/arena.cc:31:
./google/protobuf/arena.h:546: error: thread-local storage not supported for this target
google/protobuf/arena.cc:53: error: thread-local storage not supported for this target
Makefile:3507: recipe for target 'google/protobuf/arena.lo' failed
gmake[2]: *** [google/protobuf/arena.lo] Error 1
gmake[2]: Leaving directory '/home/rival/Downloads/protobuf-3.0.0-beta-1/src'
Makefile:1113: recipe for target 'all-recursive' failed
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory '/home/rival/Downloads/protobuf-3.0.0-beta-1'
Makefile:1019: recipe for target 'all' failed
gmake: *** [all] Error 2

Switching to a package version of gcc (4.9.3) and g++ (4.9.3) seems to make it complete and work so far.
so a CC=egcc and CXX=eg++ ./configure does the trick

[xfxyjwf]

Hi @eau-u4f , we don't have resources to build/test the code on OpenBSD. Could you help provide a fix? I think the problem is just that the __thread_local keyword is not supported and you only need to change this macro definition to be defined for your targeting platform:
https://github.com/google/protobuf/blob/d8b6452e37b3f9e4341569ec74f8c3ca61e82b69/src/google/protobuf/stubs/platform_macros.h#L119

[ramrunner]

Hi @xfxyjwf i can help you test on OpenBSD. Actually i just created a port for OpenBSD 6.0 and i can confirm that the patch needed is indeed the one you mentioned. (if you like to incorporate it upstream it would be great). inlined.

diff --git a/src/google/protobuf/stubs/platform_macros.h b/src/google/protobuf/stubs/platform_macros.h
index 4ba4b34..4ea1bc7 100644
--- a/src/google/protobuf/stubs/platform_macros.h
+++ b/src/google/protobuf/stubs/platform_macros.h
@@ -114,7 +114,7 @@ GOOGLE_PROTOBUF_PLATFORM_ERROR
 #undef GOOGLE_PROTOBUF_PLATFORM_ERROR
-#if defined(GOOGLE_PROTOBUF_OS_ANDROID) || defined(GOOGLE_PROTOBUF_OS_IPHONE)
+#if defined(GOOGLE_PROTOBUF_OS_ANDROID) || defined(GOOGLE_PROTOBUF_OS_IPHONE) || defined(__OpenBSD__)
 // Android ndk does not support the __thread keyword very well yet. Here
 // we use pthread_key_create()/pthread_getspecific()/... methods for
 // TLS support on android.

[xfxyjwf]

@ramrunner Can you send the patch as a pull request?

[ramrunner]

sure thing!

#2290

[vext01]

Ah nice. I was also trying to update protobuf on OpenBSD. Presumably the next release will fix this, as this is still an issue in 3.1.0.

[vext01]

FWIW, with the threadlocal patch applied, using the base OpenBSD gcc--4.2.1 now gives:

...
c++ -DHAVE_CONFIG_H -I. -I/usr/local/pobj/protobuf-cpp-3.1.0/protobuf-3.1.0/src -I.. -pthread -DHAVE_PTHREAD=1 -DHAVE_ZLIB=1 -Wall -Wno-sign-compare -O2 -pipe -MT google/protobuf/api.pb.lo -MD -MP -MF google/protobuf/.deps/api.pb.Tpo -c /usr/local/pobj/protobuf-cpp-3.1.0/protobuf-3.1.0/src/google/protobuf/api.pb.cc -fPIC -DPIC -o google/protobuf/.libs/api.pb.o
/usr/local/pobj/protobuf-cpp-3.1.0/protobuf-3.1.0/src/google/protobuf/arena.h: In static member function 'static GenericType* google::protobuf::internal::GenericTypeHandler<Type>::NewFromPrototype(const GenericType*, google::protobuf::Arena*) [with GenericType = google::protobuf::Mixin]':
/usr/local/pobj/protobuf-cpp-3.1.0/protobuf-3.1.0/src/google/protobuf/arena.h:628: sorry, unimplemented: inlining failed in call to 'static T* google::protobuf::Arena::CreateMaybeMessage(google::protobuf::Arena*, ...) [with T = google::protobuf::Mixin]': function not inlinable
/usr/local/pobj/protobuf-cpp-3.1.0/protobuf-3.1.0/src/google/protobuf/repeated_field.h:575: sorry, unimplemented: called from here
Error while executing c++ -DHAVE_CONFIG_H -I. -I/usr/local/pobj/protobuf-cpp-3.1.0/protobuf-3.1.0/src -I.. -pthread -DHAVE_PTHREAD=1 -DHAVE_ZLIB=1 -Wall -Wno-sign-compare -O2 -pipe -MT google/protobuf/api.pb.lo -MD -MP -MF google/protobuf/.deps/api.pb.Tpo -c /usr/local/pobj/protobuf-cpp-3.1.0/protobuf-3.1.0/src/google/protobuf/api.pb.cc -fPIC -DPIC -o google/protobuf/.libs/api.pb.o

[ramrunner]

@vext01 can you try with the egcc/eg++ compilers? that's what i used.
i still haven't sent an update to ports@ cause although the protobuf compiler seems to be working it's failing some tests. for reference:
https://groups.google.com/forum/#!topic/protobuf/vnRl9aAdCQ0

[vext01]

It works fine with eg{cc,++}, although it is preferable that it would work with the base compilers.

Supposing we roll with eg{cc,++}, I then have just one test failure:
#2419 (comment)

(this is with an updated gtest)

[forensic-courtofrecord]

protobuf-3.1.0 is now broken on FreeBSD 9.3 using poudriere -T (TRYBROKEN) resulting in failed builds of mumble-1.2.8_3 kde-4.14.3
We are investigating the use of newer compilers as methods to introduce hidden backdoors. Hence it is important for code to compile on the base compiler of FreeBSD 9.3

[ramrunner]

@forensic-courtofrecord can you provide any output of the failed compilation?
on openbsd we recently managed to compile latest with egcc/eg++. at least is it working on freebsd with those?