Does anybody compile protobuf successfully on HP-UX?

439 views
Skip to first unread message

Jackie

unread,
Oct 28, 2009, 2:04:31 AM10/28/09
to Protocol Buffers
I tried to compile protobuf many times on different HP machines with
version 2.1 and 2.2, but all failed. The failure reason is same as
below. Does anybody can gimme some advice ? Thank you in advance!


libtool: compile: aCC -DHAVE_CONFIG_H -I. -I.. -D_REENTRANT -
ansi_for_scope on -mthreads -c +Maked google/protobuf/io/
zero_copy_stream_impl_lite.cc -o zero_copy_stream_impl_lite.o >/dev/
null 2>&1
source='google/protobuf/stubs/strutil.cc' object='strutil.lo'
libtool=yes \
DEPDIR=.deps depmode=hp2 /bin/sh ../depcomp \
/bin/sh ../libtool --tag=CXX --mode=compile aCC -
DHAVE_CONFIG_H -I. -I.. -D_REENTRANT -mthreads -Wc,-
ansi_for_scope,on -c -o strutil.lo `test -f 'google/protobuf/stubs/
strutil.cc' || echo './'`google/protobuf/stubs/strutil.cc
libtool: compile: aCC -DHAVE_CONFIG_H -I. -I.. -D_REENTRANT -
ansi_for_scope on -mthreads -c +Maked google/protobuf/stubs/
strutil.cc -DPIC -o .libs/strutil.o
aCC: warning 901: unknown option: `-ansi_for_scope': use +help for
online documentation.
aCC: warning 901: unknown option: `-hreads': use +help for online
documentation.
aCC: warning 1913: `on' does not exist or cannot be read
"./google/protobuf/stubs/strutil.h", line 301: error #2020: identifier
"strtoll" is undefined
return strtoll(nptr, endptr, base);
^

"./google/protobuf/stubs/strutil.h", line 307: error #2020: identifier
"strtoull" is undefined
return strtoull(nptr, endptr, base);
^

"google/protobuf/stubs/strutil.cc", line 217: error #2101: "iter" has
already
been declared in the current scope
for (ITERATOR iter = start; iter != end; ++iter) {
^
detected during instantiation of "void
google::protobuf::JoinStringsIterator(const
ITERATOR &,
const ITERATOR &, const char *, std::string *)
[with
ITERATOR=std::vector<std::string,
std::allocator<std::string>>::const_iterator]" at
line 228

"google/protobuf/stubs/strutil.cc", line 662: warning #2177-D:
function
"google::protobuf::PlaceNum" was declared but never
referenced
static inline char* PlaceNum(char* p, int num, char prev_sep) {
^

3 errors detected in the compilation of "google/protobuf/stubs/
strutil.cc".
*** Error exit code 1

Stop.
*** Error exit code 1

Stop.
*** Error exit code 1


Here's part of config.log:

$ ./configure CXXFLAGS=-Wc,-ansi_for_scope,on --prefix=/BEA/icscomp/
soft/GNU

## --------- ##
## Platform. ##
## --------- ##

hostname = SID-1
uname -m = ia64
uname -r = B.11.23
uname -s = HP-UX
uname -v = U

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown

Kenton Varda

unread,
Oct 28, 2009, 5:05:17 PM10/28/09
to Jackie, Protocol Buffers
It appears that your system lacks strtoll().  You'll need to replace it somehow.  Is your system 64-bit?  If so, strtol() should work fine.  There's actually an #ifdef near the top of strutil.h which deals with this for other systems.

As for the "iter has already been declared" problem, it looks like your compiler is using very old rules regarding scope of variables declared in for() loops.  I noticed that it is also suspiciously complaining that it doesn't recognize the "-ansi_for_scope" flag, which it appears you specified yourself.  Presumably getting this flag to work would fix the problem.

Jackie

unread,
Nov 13, 2009, 6:09:47 AM11/13/09
to Protocol Buffers
Hello Kenton,

My system is 64-bit. I wrote a small sample to test strtoll(), and
surprisedly found it is not enabled by default, actually an extra
option "-ext" is needed. As for the "iter has already been declared"
problem, there is also an extra option: "-Wc,ansi_for_scope,on", but
this option can not passed into autoconf directly due to its strange
form. Lucky thing is that we can enable this option by another way: "-
AA" or "-Aa". That is exactly what I've done now. Here's my compiling
command line:
$ ./configure CXXFLAGS="-ext -AA"

Unfortunately, my good luck can not last to the end :(
Another error is reported as below, which seems to tell me that aCC's
standard header file is wrong. I'm confused.
pls kindly gimme some help. THANK YOU!

"
Making all in src
source='google/protobuf/compiler/command_line_interface.cc'
object='command_line_interface.lo' libtool=yes \
DEPDIR=.deps depmode=hp2 /bin/sh ../depcomp \
/bin/sh ../libtool --tag=CXX --mode=compile aCC -DHAVE_CONFIG_H -
I. -I.. -D_REENTRANT -mthreads -ext -Aa -c -o
command_line_interface.lo `test -f 'google/protobuf/compiler/
command_line_interface.cc' || echo './'`google/protobuf/compiler/
command_line_interface.cc
libtool: compile: aCC -DHAVE_CONFIG_H -I. -I.. -D_REENTRANT -mthreads
-ext -Aa -c +Maked google/protobuf/compiler/command_line_interface.cc
-DPIC -o .libs/command_line_interface.o
aCC: warning 901: unknown option: `-hreads': use +help for online
documentation.
"/opt/aCC/include_std/utility", line 103: error #2144: a value of type
"const char *" cannot be used to initialize an entity of type
"std::pair<char [1], char [2]>::first_type"
: first (__x), second (__y) { }
^
detected during:
instantiation of "std::pair<_TypeT, _TypeU>::pair(const
std::pair<_TypeT, _TypeU>::first_type &, const std::pair<_TypeT,
_TypeU>::second_type &) [with _TypeT=char [1], _TypeU=char [2]]" at
line 181
instantiation of "std::pair<_TypeT, _TypeU> std::make_pair
(const _TypeT &, const _TypeU &) [with _TypeT=char [1], _TypeU=char
[2]]" at line 477 of "google/protobuf/compiler/
command_line_interface.cc"

"/opt/aCC/include_std/utility", line 103: error #2144: a value of type
"const char *" cannot be used to initialize an entity of type
"std::pair<char [1], char [2]>::second_type"
: first (__x), second (__y) { }
^
detected during:
instantiation of "std::pair<_TypeT, _TypeU>::pair(const
std::pair<_TypeT, _TypeU>::first_type &, const std::pair<_TypeT,
_TypeU>::second_type &) [with _TypeT=char [1], _TypeU=char [2]]" at
line 181
instantiation of "std::pair<_TypeT, _TypeU> std::make_pair
(const _TypeT &, const _TypeU &) [with _TypeT=char [1], _TypeU=char
[2]]" at line 477 of "google/protobuf/compiler/
command_line_interface.cc"

2 errors detected in the compilation of "google/protobuf/compiler/
command_line_interface.cc".
*** Error exit code 1

Stop.
*** Error exit code 1

Stop.
*** Error exit code 1

Stop.
"

On Oct 29, 5:05 am, Kenton Varda <ken...@google.com> wrote:
> It appears that your system lacks strtoll().  You'll need to replace it
> somehow.  Is your system 64-bit?  If so, strtol() should work fine.  There's
> actually an #ifdef near the top of strutil.h which deals with this for other
> systems.
>
> As for the "iter has already been declared" problem, it looks like your
> compiler is using very old rules regarding scope of variables declared in
> for() loops.  I noticed that it is also suspiciously complaining that it
> doesn't recognize the "-ansi_for_scope" flag, which it appears you specified
> yourself.  Presumably getting this flag to work would fix the problem.
>

Kenton Varda

unread,
Nov 13, 2009, 12:47:09 PM11/13/09
to Jackie, Protocol Buffers
Line 477 of src/google/protobuf/compiler/command_line_interface.cc says:
    proto_path_.push_back(make_pair("", "."));
Try changing it to:
    proto_path_.push_back(make_pair(string(""), string(".")));

If this works I will commit it to SVN.

Jackie

unread,
Nov 15, 2009, 11:12:25 PM11/15/09
to Protocol Buffers
Yes, it works! Thank you, Kenton :)

And I got another error report:

./ -I. --cpp_out=.
sh: ./: Execute permission denied.
*** Error exit code 126

which is located in line 2552 of src/Makefile :
2551 unittest_proto_middleman: protoc$(EXEEXT) $(protoc_inputs)
2552 ./$^ -I$(srcdir) --cpp_out=.
2553 touch unittest_proto_middleman

I noticed that there's some comments above the line:
2548 # For reference, if we didn't have to worry about VPATH (i.e.,
building from
2549 # a directory other than the package root), we could have just
written this:
2550 # ./protoc$(EXEEXT) -I$(srcdir) --cpp_out=. $(protoc_inputs)

I don't worry about VPATH, so I modified the line as below:
2551 unittest_proto_middleman: protoc$(EXEEXT) $(protoc_inputs)
2552 ./protoc$(EXEEXT) -I$(srcdir) --cpp_out=. $(protoc_inputs)
2553 touch unittest_proto_middleman

Then everything is O.K. :)

BTW, I noticed lots of warnings printed during the whole process of
compiling and linking, like this:

libtool: compile: aCC -DHAVE_CONFIG_H -I. -I.. -D_REENTRANT -mthreads
-ext -Aa -c +Maked google/protobuf/compiler/cpp/cpp_message.cc -o
cpp_message.o >/dev/null 2>&1
source='google/protobuf/compiler/cpp/cpp_message_field.cc'
object='cpp_message_field.lo' libtool=yes \
DEPDIR=.deps depmode=hp2 /bin/sh ../depcomp \
/bin/sh ../libtool --tag=CXX --mode=compile aCC -DHAVE_CONFIG_H -
I. -I.. -D_REENTRANT -mthreads -ext -Aa -c -o cpp_message_field.lo
`test -f 'google/protobuf/compiler/cpp/cpp_message_field.cc' || echo
'./'`google/protobuf/compiler/cpp/cpp_message_field.cc
libtool: compile: aCC -DHAVE_CONFIG_H -I. -I.. -D_REENTRANT -mthreads
-ext -Aa -c +Maked google/protobuf/compiler/cpp/cpp_message_field.cc -
DPIC -o .libs/cpp_message_field.o
aCC: warning 901: unknown option: `-hreads': use +help for online
documentation.

/bin/sh ../libtool --tag=CXX --mode=link aCC -D_REENTRANT -
mthreads -ext -Aa -version-info 4:0:0 -o libprotoc.la -rpath /BEA/
icscomp/soft/GNU/lib code_generator.lo command_line_interface.lo
cpp_enum.lo cpp_enum_field.lo cpp_extension.lo cpp_field.lo
cpp_file.lo cpp_generator.lo cpp_helpers.lo cpp_message.lo
cpp_message_field.lo cpp_primitive_field.lo cpp_service.lo
cpp_string_field.lo java_enum.lo java_enum_field.lo java_extension.lo
java_field.lo java_file.lo java_generator.lo java_helpers.lo
java_message.lo java_message_field.lo java_primitive_field.lo
java_service.lo python_generator.lo libprotobuf.la
libtool: link: aCC -b -Wl,+h -Wl,libprotoc.so.4 -Wl,+nodefaultrpath -
o .libs/libprotoc.so.4.0 .libs/code_generator.o .libs/
command_line_interface.o .libs/cpp_enum.o .libs/cpp_enum_field.o .libs/
cpp_extension.o .libs/cpp_field.o .libs/cpp_file.o .libs/
cpp_generator.o .libs/cpp_helpers.o .libs/cpp_message.o .libs/
cpp_message_field.o .libs/cpp_primitive_field.o .libs/
cpp_service.o .libs/cpp_string_field.o .libs/java_enum.o .libs/
java_enum_field.o .libs/java_extension.o .libs/java_field.o .libs/
java_file.o .libs/java_generator.o .libs/java_helpers.o .libs/
java_message.o .libs/java_message_field.o .libs/
java_primitive_field.o .libs/java_service.o .libs/python_generator.o
-Wl,+b -Wl,/BEA/icscomp/kk/google/protobuf-2.2.0/src/.libs:/BEA/
icscomp/soft/GNU/lib ./.libs/libprotobuf.so -mthreads -mthreads
aCC: warning 901: unknown option: `-hreads': use +help for online
documentation.
aCC: warning 901: unknown option: `-hreads': use +help for online
documentation.

I guess this is caused by protobuf-2.2.0/m4/acx_pthread.m4. Maybe
you can take a look at that little problem when you're free.



On Nov 14, 1:47 am, Kenton Varda <ken...@google.com> wrote:
> Line 477 of src/google/protobuf/compiler/command_line_interface.cc says:
>     proto_path_.push_back(make_pair("", "."));
> Try changing it to:
>     proto_path_.push_back(make_pair(string(""), string(".")));
>
> If this works I will commit it to SVN.
>

Kenton Varda

unread,
Nov 17, 2009, 4:07:54 PM11/17/09
to Jackie, Protocol Buffers
On Sun, Nov 15, 2009 at 8:12 PM, Jackie <junkan...@gmail.com> wrote:

Yes, it works! Thank you, Kenton :)

And I got another error report:

       ./ -I. --cpp_out=.
sh: ./: Execute permission denied.
*** Error exit code 126

This can also be fixed by using GNU make instead of your system's make.
 
BTW, I noticed lots of warnings printed during the whole process of
compiling and linking, like this:

It looks like acx_pthread.m4 loops through a set of flags trying to find the one that makes pthreads work.  One of the things it tries is -mthreads, which is apparently used by mingw32.  It happens that your compiler does not fail when given this flag (it only prints a warning), and then apparently pthreads work correctly by coincidence.  So the script decides to use this flag.

Since it looks like nothing is actually wrong except for some spurious warnings, I'm not going to look into fixing this myself, but feel free to send me a patch if you want.
Reply all
Reply to author
Forward
0 new messages