protoc just segfaults on FreeBSD 10-RELEASE arm

[GoogleCodeExporter]

What steps will reproduce the problem?
1. FreeBSD on a raspberry pi (or other ARM architecture?)
2. ./configure CXXFLAGS="-DNDEBUG -O0 -g"; make, or just ./configure; make
3. Using clang that comes with FreeBSD 10-RELEASE

On FreeBSD ports, the devel/protobuf port is marked ONLY_FOR_ARCHS=i386 amd64.

c++: warning: argument unused during compilation: '-pthread'
libtool: link: (cd ".libs" && rm -f "libprotoc.so" && ln -s "libprotoc.so.8" 
"libprotoc.so")
libtool: link: (cd ".libs" && rm -f "libprotoc.so" && ln -s "libprotoc.so.8" 
"libprotoc.so")
libtool: link: ar cru .libs/libprotoc.a  code_generator.o 
command_line_interface.o plugin.o plugin.pb.o subprocess.o zip_writer.o 
cpp_enum.o cpp_enum_field.o cpp_extension.o cpp_field.o cpp_file.o 
cpp_generator.o cpp_helpers.o cpp_message.o cpp_message_field.o 
cpp_primitive_field.o cpp_service.o cpp_string_field.o java_enum.o 
java_enum_field.o java_extension.o java_field.o java_file.o java_generator.o 
java_helpers.o java_message.o java_message_field.o java_primitive_field.o 
java_service.o java_string_field.o java_doc_comment.o python_generator.o
libtool: link: ranlib .libs/libprotoc.a
libtool: link: ( cd ".libs" && rm -f "libprotoc.la" && ln -s "../libprotoc.la" 
"libprotoc.la" )
/bin/sh ../libtool --tag=CXX    --mode=link c++ -D_THREAD_SAFE -pthread -Wall 
-Wwrite-strings -Woverloaded-virtual -Wno-sign-compare  -DNDEBUG -O0 -g 
-D_THREAD_SAFE -pthread   -o protoc main.o -lpthread libprotobuf.la 
libprotoc.la -lz
libtool: link: c++ -D_THREAD_SAFE -pthread -Wall -Wwrite-strings 
-Woverloaded-virtual -Wno-sign-compare -DNDEBUG -O0 -g -D_THREAD_SAFE -pthread 
-o .libs/protoc main.o  ./.libs/libprotobuf.so ./.libs/libprotoc.so 
/usr/home/pcoutin/protobuf-2.5.0/src/.libs/libprotobuf.so -lpthread -lz 
-pthread -Wl,-rpath -Wl,/usr/local/lib
oldpwd=`pwd` && ( cd . && $oldpwd/protoc -I. --cpp_out=$oldpwd 
google/protobuf/unittest.proto                                
google/protobuf/unittest_empty.proto                          
google/protobuf/unittest_import.proto                         
google/protobuf/unittest_import_public.proto                  
google/protobuf/unittest_mset.proto                           
google/protobuf/unittest_optimize_for.proto                   
google/protobuf/unittest_embed_optimize_for.proto             
google/protobuf/unittest_custom_options.proto                 
google/protobuf/unittest_lite.proto                           
google/protobuf/unittest_import_lite.proto                    
google/protobuf/unittest_import_public_lite.proto             
google/protobuf/unittest_lite_imports_nonlite.proto           
google/protobuf/unittest_no_generic_services.proto            
google/protobuf/compiler/cpp/cpp_test_bad_identifiers.proto )
*** Signal 11

Stop.
make[2]: stopped in /usr/home/pcoutin/protobuf-2.5.0/src
*** Error code 1

Stop.
make[1]: stopped in /usr/home/pcoutin/protobuf-2.5.0
*** Error code 1

Stop.
make: stopped in /usr/home/pcoutin/protobuf-2.5.0

Doing a backtrace with gdb just shows:
Program received signal SIGSEGV, Segmentation fault.
0xffff0fa0 in ?? ()

- What is the expected output? What do you see instead?
 A proper test result, but the program just segfaults in the unit test
 after building. Just running protoc with no arguments or anything results
 in a segmentation fault.

- What version of the product are you using? On what operating system?
 protobuf 2.5.0 on FreeBSD 10-RELEASE arm.

FreeBSD ... 10.0-RELEASE FreeBSD 10.0-RELEASE #1 r261314M: Fri Jan 31 18:04:51 
PST 2014     pcoutin@thorn.local:/usr/obj/arm.armv6/usr/src/sys/RPI-B  arm

FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
Target: armv6--freebsd10.0-gnueabi
Thread model: posix

Original issue reported on code.google.com by pedrolea...@gmail.com on 9 Feb 2014 at 2:15

[GoogleCodeExporter]

protobuf 2.4.1 successfully built on the same system.

Original comment by pedrolea...@gmail.com on 13 Feb 2014 at 7:23

[GoogleCodeExporter]

This also occurs on FreeBSD 11 on Cubieboard2.
Although this could also be a clang issue, I'll try building with GCC.

Original comment by v1ne...@gmail.com on 13 Jul 2014 at 11:04