[protobuf] Integrated support with SQL
Hi Team, Most of the time me and my peers, spend a lot of time creating protos for the entities/tables in database and auto converters for the same which seems to be repetitive work (with different field names). I wanted to know if we can provide support for generation of proto file based on the sql script for creating tables which the developer can modify to their need. It would parse the script and generate equivalent protos. With a configurable file, the names of the protos, location of the protos could be configured. This will save a lot of development time for developers. I am working with AppsFramework and MySQL but if this can be generalized to other databases I believe it would help. Any thoughts on the same? (Open for a 20% project contribution for the same) Thank you, -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/protobuf/7e6f8d81-0787-4693-b7ba-77caf727bb14n%40googlegroups.com.
[protobuf] Re: STL_HASH.m4
Hi,
I tried to debug implementation which initializes kTypeNames.
It seems like MakeTypeNameTable() function is not called
which causes uninitialized kTypeNames. I tried to convert kTypeNames
to static variable but still it didn't work.Then I made it global
variable and modified this function to insert keys and values directly
to kTypeNames. To achieve this I called MakeTypeNameTable() from
Parser class constructor but then I got segmentation fault at first
assignment in MakeTypeNameTable().
Parser.cc:
namespace {
typedef hash_mapstring, FieldDescriptorProto::Type TypeNameMap;
TypeNameMap MakeTypeNameTable() {
TypeNameMap result;
result[double ] = FieldDescriptorProto::TYPE_DOUBLE;
result[float ] = FieldDescriptorProto::TYPE_FLOAT;
result[uint64 ] = FieldDescriptorProto::TYPE_UINT64;
result[fixed64 ] = FieldDescriptorProto::TYPE_FIXED64;
result[fixed32 ] = FieldDescriptorProto::TYPE_FIXED32;
result[bool] = FieldDescriptorProto::TYPE_BOOL;
result[string ] = FieldDescriptorProto::TYPE_STRING;
result[group ] = FieldDescriptorProto::TYPE_GROUP;
result[bytes ] = FieldDescriptorProto::TYPE_BYTES;
result[uint32 ] = FieldDescriptorProto::TYPE_UINT32;
result[sfixed32] = FieldDescriptorProto::TYPE_SFIXED32;
result[sfixed64] = FieldDescriptorProto::TYPE_SFIXED64;
result[int32 ] = FieldDescriptorProto::TYPE_INT32;
result[int64 ] = FieldDescriptorProto::TYPE_INT64;
result[sint32 ] = FieldDescriptorProto::TYPE_SINT32;
result[sint64 ] = FieldDescriptorProto::TYPE_SINT64;
return result;
}
const TypeNameMap kTypeNames = MakeTypeNameTable();
} // anonymous namespace
Similarly in other test program I created to check whether compiler
behaves correctly for anonymous namespace so it seems to be working
correctly...
here hash_map is basically inherited from unordered_map . This is
basically borrowed from hash.h in google protocol buffer source.
namespace test2
{
namespace {
typedef test::hash_mapstring, TestDataType1::DATA_Type TypeNameMap;
TypeNameMap MakeTypeNameTable() {
TypeNameMap result;
result[double ] = TestDataType1::TYPE_DOUBLE;
result[float ] = TestDataType1::TYPE_FLOAT;
result[uint64 ] = TestDataType1::TYPE_UINT64;
result[fixed64 ] = TestDataType1::TYPE_FIXED64;
result[fixed32 ] = TestDataType1::TYPE_FIXED32;
result[bool] = TestDataType1::TYPE_BOOL;
result[string ] = TestDataType1::TYPE_STRING;
result[group ] = TestDataType1::TYPE_GROUP;
result[bytes ] = TestDataType1::TYPE_BYTES;
result[uint32 ] = TestDataType1::TYPE_UINT32;
result[sfixed32] = TestDataType1::TYPE_SFIXED32;
result[sfixed64] = TestDataType1::TYPE_SFIXED64;
result[int32 ] = TestDataType1::TYPE_INT32;
result[int64 ] = TestDataType1::TYPE_INT64;
result[sint32 ] = TestDataType1::TYPE_SINT32;
result[sint64 ] = TestDataType1::TYPE_SINT64;
return result;
}
const TypeNameMap kTypeNames = MakeTypeNameTable();
} // anonymous namespace
void testUnorderedMap()
{
int i =0;
std::cout Printing first map ;
for(TypeNameMap::const_iterator it = kTypeNames.begin();
it != kTypeNames.end();
++it)
{
std::cout [ it-first , it-second ] ;
}
}
}//test2 namespace
Thanks Regards,
Vikram
On Jan 19, 8:11 pm, Kenton Varda ken...@google.com wrote:
I have no idea.
On Tue, Jan 19, 2010 at 7:58 PM, vikram patil patilvik...@gmail.com wrote:
Thanks Kenton. I will try to debug it and will let you know. Did anyone
successfully compiled protocol buffer on AIX ? I've seen couple of posts but
never saw some reply with success.
Thanks Regards,
Vikram
On Tue, Jan 19, 2010 at 7:56 PM, Kenton Varda ken...@google.com wrote:
It just looks up the type name in a hash_map:
http://code.google.com/p/protobuf/source/browse/trunk/src/google/prot...
http://code.google.com/p/protobuf/source/browse/trunk/src/google/prot...kTypeNames
is initialized here:
http://code.google.com/p/protobuf/source/browse/trunk/src/google/prot...
On Tue, Jan 19, 2010 at 7:53 PM, vikram patil patilvik...@gmail.comwrote:
Hmm
Could you please point me to code which is responsible for recognizing
built in types ? I will try to debug more . My independent tests which
evaluates unordered_map are working fine. But when I am trying to use it
with protocol buffer it fails.
Thanks Regards,
Vikram
On Tue, Jan 19, 2010 at 7:48 PM, Kenton Varda ken...@google.com wrote:
Wait, I misread your error report. It looks like the errors are coming
from protoc. However, the errors are very odd -- it appears that protoc
is
failing to recognize built-in types like string and int32. This
could
happen if the hash_map/unordered_map implementation is broken and not
properly matching string keys.
On Tue, Jan 19, 2010 at 6:53 PM, Kenton Varda ken...@google.comwrote:
This sounds like another problem with your compiler -- it can't find
std::string.
Note that in common.h we use using
[protobuf] Re: STL_HASH.m4
Thanks Kenton, I configured correctly using following configure
string
./configure CC=/compiler/xlcpp/usr/vac/bin/xlc_r CXX=/compiler/
xlcpp/usr/vacpp/bin/xlC_r CXXFLAGS=-g -qlanglvl=extended -
D__IBMCPP_TR1__ -qidirfirst -I/compiler/xlcpp/usr/vacpp/include
CFLAGS=-g -qlanglvl=extc99
Configure detects unordered_map correctly and uses that but when I
tried with simple proto file I got following error
bash-3.00$ ./lt-protoc -I. test.proto --cpp_out=.
test.proto:4:12: string is not defined.
test.proto:5:12: int32 is not defined.
test.proto:6:12: int32 is not defined.
test.proto
package tutorial;
message SearchRequest {
required string query = 1;
optional int32 page_number = 2;
optional int32 result_per_page = 3;
}
Its seems like descriptor.cc hold kTypeTonName map which identifies
basic google protocol buffer supported datatypes but compiled compiler
could not figure it out.
It seems like function using this array is never called when I
debugged
Function from descriptor.cc
void FieldDescriptor::DebugString(int depth, string *contents) const {
Please provide some idea on this
Thanks Regards,
Vikram
On Jan 13, 2:17 pm, Kenton Varda ken...@google.com wrote:
stl_hash.m4 should automatically look it whatever directory your compiler
uses. If for some reason your compiler does not automatically look in the
directory you want, then you should add the proper CXXFLAGS to make it look
there, e.g.:
./configure CXXFLAGS=-I/XYZ/vacpp/include
(-I is GCC's flag for this; your compiler may be different.)
On Wed, Jan 13, 2010 at 12:20 PM, vikram patilvik...@gmail.com wrote:
Hello Guys,
I am seeing that google protocol buffer is now supporting
unorderd_map with new modification in hash.h . But I am confused where
exactly stl_hash.m4 looks for unordered_map by default . Can we make
it to look in different directly as xlc compiler on AIX is installed
under XYZ/vacpp/include which is different that default /usr/include
directory?
I tried to run m4 with stl_hash.m4 as input and XYZ/vacpp/include as
include directory but it failed. saying end quote is not provided
Is there anyway I can make stl_hash.m4 to look into
different include file than /usr/include
Thanks Regards,
Vikram
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Re: STL_HASH.m4
Thanks Kenton. I will try to debug it and will let you know. Did anyone
successfully compiled protocol buffer on AIX ? I've seen couple of posts but
never saw some reply with success.
Thanks Regards,
Vikram
On Tue, Jan 19, 2010 at 7:56 PM, Kenton Varda ken...@google.com wrote:
It just looks up the type name in a hash_map:
http://code.google.com/p/protobuf/source/browse/trunk/src/google/protobuf/compiler/parser.cc#1007
http://code.google.com/p/protobuf/source/browse/trunk/src/google/protobuf/compiler/parser.cc#1007kTypeNames
is initialized here:
http://code.google.com/p/protobuf/source/browse/trunk/src/google/protobuf/compiler/parser.cc#61
On Tue, Jan 19, 2010 at 7:53 PM, vikram patil patilvik...@gmail.comwrote:
Hmm
Could you please point me to code which is responsible for recognizing
built in types ? I will try to debug more . My independent tests which
evaluates unordered_map are working fine. But when I am trying to use it
with protocol buffer it fails.
Thanks Regards,
Vikram
On Tue, Jan 19, 2010 at 7:48 PM, Kenton Varda ken...@google.com wrote:
Wait, I misread your error report. It looks like the errors are coming
from protoc. However, the errors are very odd -- it appears that protoc is
failing to recognize built-in types like string and int32. This could
happen if the hash_map/unordered_map implementation is broken and not
properly matching string keys.
On Tue, Jan 19, 2010 at 6:53 PM, Kenton Varda ken...@google.com wrote:
This sounds like another problem with your compiler -- it can't find
std::string.
Note that in common.h we use using namespace std; to import all of std
into the google::protobuf namespace. This is not good practice but we
didn't think it was worth the effort to fix it.
On Tue, Jan 19, 2010 at 6:42 PM, vikram patilvik...@gmail.com wrote:
Thanks Kenton, I configured correctly using following configure
string
./configure CC=/compiler/xlcpp/usr/vac/bin/xlc_r CXX=/compiler/
xlcpp/usr/vacpp/bin/xlC_r CXXFLAGS=-g -qlanglvl=extended -
D__IBMCPP_TR1__ -qidirfirst -I/compiler/xlcpp/usr/vacpp/include
CFLAGS=-g -qlanglvl=extc99
Configure detects unordered_map correctly and uses that but when I
tried with simple proto file I got following error
bash-3.00$ ./lt-protoc -I. test.proto --cpp_out=.
test.proto:4:12: string is not defined.
test.proto:5:12: int32 is not defined.
test.proto:6:12: int32 is not defined.
test.proto
package tutorial;
message SearchRequest {
required string query = 1;
optional int32 page_number = 2;
optional int32 result_per_page = 3;
}
Its seems like descriptor.cc hold kTypeTonName map which identifies
basic google protocol buffer supported datatypes but compiled compiler
could not figure it out.
It seems like function using this array is never called when I
debugged
Function from descriptor.cc
void FieldDescriptor::DebugString(int depth, string *contents) const {
Please provide some idea on this
Thanks Regards,
Vikram
On Jan 13, 2:17 pm, Kenton Varda ken...@google.com wrote:
stl_hash.m4 should automatically look it whatever directory your
compiler
uses. If for some reason your compiler does not automatically look
in the
directory you want, then you should add the proper CXXFLAGS to make
it look
there, e.g.:
./configure CXXFLAGS=-I/XYZ/vacpp/include
(-I is GCC's flag for this; your compiler may be different.)
On Wed, Jan 13, 2010 at 12:20 PM, vikram patilvik...@gmail.com
wrote:
Hello Guys,
I am seeing that google protocol buffer is now supporting
unorderd_map with new modification in hash.h . But I am confused
where
exactly stl_hash.m4 looks for unordered_map by default . Can we
make
it to look in different directly as xlc compiler on AIX is
installed
under XYZ/vacpp/include which is different that default
/usr/include
directory?
I tried to run m4 with stl_hash.m4 as input and XYZ/vacpp/include
as
include directory but it failed. saying end quote is not
provided
Is there anyway I can make stl_hash.m4 to look into
different include file than /usr/include
Thanks Regards,
Vikram
--
You received this message because you are subscribed to the Google
Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
protobuf%2bunsubscr...@googlegroups.comprotobuf%252bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
You received this message because you are subscribed to the Google
Groups Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
.
For more options, visit this group
[protobuf] STL_HASH.m4
Hello Guys, I am seeing that google protocol buffer is now supporting unorderd_map with new modification in hash.h . But I am confused where exactly stl_hash.m4 looks for unordered_map by default . Can we make it to look in different directly as xlc compiler on AIX is installed under XYZ/vacpp/include which is different that default /usr/include directory? I tried to run m4 with stl_hash.m4 as input and XYZ/vacpp/include as include directory but it failed. saying end quote is not provided Is there anyway I can make stl_hash.m4 to look into different include file than /usr/include Thanks Regards, Vikram -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Configure problems
Hi guys, I am trying to compiler protocol buffer on AIX with xlC++ compiler. I tried this one last year but I didn't have much success. Now I am revisiting it . I saw that there is support for unordered_map unordered_set in protocol buffer in HP-UX. I want to extend it to AIX. But I am having following issue as xlC compiler could not take --version as option but -qVersion as version option. Could you please suggest some solution to fix this? From config log configure:2303: checking for C compiler version configure:2306: xlc_r --version /dev/null 5 xlc_r: 1501-216 (W) command option --version is not recognized - passed to ld Thanks Regards, Vikram -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Compilation issue on Solaris 9 with CC version 5.9
Hello Guys, I have generated protocol buffer header files and source files from proto and compiled those with include files on linux without any issues. Here I am trying to use same source files with same include directory but on solaris so I have encountered following problems. Does anyone have same issues while working with protobuf 2.1.0 (*)() in call to pthread_once(_once*, extern C void(*)()) is being passed void(*)(). /work//SunBuild/Server/../Tools/protobuf/include/google/protobuf/ descriptor.h, line 324: Warning: Identifier expected instead of }. /work//SunBuild/Server/../Tools/protobuf/include/google/protobuf/ descriptor.h, line 343: Warning: Identifier expected instead of }. /work////SunBuild/Server/../Tools/protobuf/include/google/ protobuf/descriptor.h, line 354: Warning: Identifier expected instead of }. /work////SunBuild/Server/../Tools/protobuf/include/google/ protobuf/wire_format.h, line 177: Warning: Identifier expected instead of }. /work////SunBuild/Server/../Tools/protobuf/include/google/ protobuf/descriptor.pb.h, line 83: Error: Unexpected type name google::protobuf::FieldDescriptorProto_Type encountered. /work////SunBuild/Server/../Tools/protobuf/include/google/ protobuf/descriptor.pb.h, line 102: Error: Unexpected type name google::protobuf::FieldDescriptorProto_Label encountered. /work////SunBuild/Server/../Tools/protobuf/include/google/ protobuf/descriptor.pb.h, line 120: Error: Unexpected type name google::protobuf::FileOptions_OptimizeMode encountered. /work////SunBuild/Server/../Tools/protobuf/include/google/ protobuf/descriptor.pb.h, line 138: Error: Unexpected type name google::protobuf::FieldOptions_CType encountered. 4 Error(s) and 5 Warning(s) detected. Thanks Regards, Vikram --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Compiling on AIX 5.3 using xlC 3.55 compiler
In previous attempt small test worked but was not able to work with
protocol buffer source code.
I tried one more thing as
#if deinfed (MISSING_HASH_MAP) defined (__xlC__)
#define hash_map std::tr1::unordered_map
google/protobuf/unittest.proto:85:37: Expected ;.
google/protobuf/unittest.proto:117:37: Expected ;.
google/protobuf/unittest.proto:133:55: Expected identifier.
google/protobuf/unittest.proto:134:55: Expected identifier.
google/protobuf/unittest.proto:135:55: Expected identifier.
google/protobuf/unittest.proto:136:55: Expected identifier.
google/protobuf/unittest.proto:137:54: Expected identifier.
google/protobuf/unittest.proto:138:55: Expected identifier.
google/protobuf/unittest.proto:139:55: Expected identifier.
google/protobuf/unittest.proto:140:55: Expected identifier.
google/protobuf/unittest.proto:141:55: Expected identifier.
google/protobuf/unittest.proto:142:54: Expected identifier.
google/protobuf/unittest.proto:143:55: Expected identifier.
google/protobuf/unittest.proto:144:55: Expected identifier.
google/protobuf/unittest.proto:146:54: Expected identifier.
google/protobuf/unittest.proto:147:54: Expected identifier.
google/protobuf/unittest.proto:154:73: Expected identifier.
google/protobuf/unittest.proto:155:57: Expected identifier.
google/protobuf/unittest.proto:192:47: Expected ;.
google/protobuf/unittest.proto:226:47: Expected ;.
google/protobuf/unittest.proto:244:65: Expected identifier.
google/protobuf/unittest.proto:245:65: Expected identifier.
google/protobuf/unittest.proto:246:65: Expected identifier.
google/protobuf/unittest.proto:247:65: Expected identifier.
google/protobuf/unittest.proto:248:64: Expected identifier.
google/protobuf/unittest.proto:249:65: Expected identifier.
google/protobuf/unittest.proto:250:65: Expected identifier.
google/protobuf/unittest.proto:251:65: Expected identifier.
google/protobuf/unittest.proto:252:65: Expected identifier.
google/protobuf/unittest.proto:253:64: Expected identifier.
google/protobuf/unittest.proto:254:65: Expected identifier.
google/protobuf/unittest.proto:255:65: Expected identifier.
google/protobuf/unittest.proto:257:64: Expected identifier.
google/protobuf/unittest.proto:258:64: Expected identifier.
google/protobuf/unittest.proto:268:64: Expected identifier.
google/protobuf/unittest.proto:269:68: Expected identifier.
google/protobuf/unittest.proto:276:42: Expected identifier.
google/protobuf/unittest.proto:379:26: Expected ;.
google/protobuf/unittest.proto:380:26: Expected ;.
google/protobuf/unittest.proto:451:47: Expected identifier.
google/protobuf/unittest.proto:452:47: Expected identifier.
google/protobuf/unittest.proto:453:47: Expected identifier.
google/protobuf/unittest.proto:454:47: Expected identifier.
google/protobuf/unittest.proto:455:47: Expected identifier.
google/protobuf/unittest.proto:460:46: Expected identifier.
gmake: *** [unittest_proto_middleman] Error 1
So I guess it wont even compile with unordered_map provided on Linux .
Please provide some inputs on this one.
Thanks Regards,
Vikram
On Jul 14, 6:35 pm, Kenton Varda ken...@google.com wrote:
It looks like your implementation of hash_map is not working correctly --
all lookups are failing. You might try writing a little test for hash_map
itself that would be easier to debug.
On Tue, Jul 14, 2009 at 6:27 PM, vikram patilvik...@gmail.com wrote:
Kenton Monty,
I added hack as followes in the hash.h
// File changed .
#if defined(HAVE_HASH_MAP) defined(HAVE_HASH_SET)
#include HASH_MAP_H
#include HASH_SET_H
#elif defined (__xlC__)
#define MISSING_HASH
#include unordered_map
#include unordered_set
#else
#define MISSING_HASH
#include map
#include set
#endif
namespace google {
namespace protobuf {
#if defined(MISSING_HASH) defined(__xlC__)
//@TODO
//Inherit hash_map from unordered_map
template typename Key
struct hash : public std::tr1::hashKey {
};
template typename Key
struct hashconst Key* {
inline size_t operator()(const Key* key) const {
return reinterpret_castsize_t(key);
}
};
template typename Key, typename Data,
typename HashFcn = hashKey,
typename EqualKey = std::equal_toKey
class hash_map : public std::tr1::unordered_mapKey, Data, HashFcn ,
EqualKey {
};
template typename Key,
typename HashFcn = hashKey,
typename EqualKey = std::equal_toKey
class hash_set : public std::tr1::unordered_set
Key, HashFcn, EqualKey {
};
#elif defined(MISSING_HASH)
File continues as it is
Stack trace
pthread_kill(??, ??) at 0xd01246b4
_p_raise(??) at 0xd0124124
raise.raise(??) at 0xd0375b28
abort() at 0xd03d3e78
google::protobuf::internal::LogMessage::Finish()(this = 0x2ff21e40),
line 171 in common.cc
google::protobuf::internal::LogFinisher::operator=
(google::protobuf::internal::LogMessage)(this = 0x2ff21e38, other =
(...)), line 176 in common.cc
Re: Compiling on AIX 5.3 using xlC 3.55 compiler
is not defined. libprotobuf ERROR google/protobuf/descriptor.cc:2218] google.protobuf.DescriptorProto.enum_type: .google.protobuf.EnumDescriptorProto is not defined. libprotobuf ERROR google/protobuf/descriptor.cc:2218] google.protobuf.DescriptorProto.extension_range: .google.protobuf.DescriptorProto.ExtensionRange is not defined. libprotobuf ERROR google/protobuf/descriptor.cc:2218] google.protobuf.DescriptorProto.options: .google.protobuf.MessageOptions is not defined. libprotobuf ERROR google/protobuf/descriptor.cc:2218] google.protobuf.FieldDescriptorProto.label: .google.protobuf.FieldDescriptorProto.Label is not defined. libprotobuf ERROR google/protobuf/descriptor.cc:2218] google.protobuf.FieldDescriptorProto.type: .google.protobuf.FieldDescriptorProto.Type is not defined. libprotobuf ERROR google/protobuf/descriptor.cc:2218] google.protobuf.FieldDescriptorProto.options: .google.protobuf.FieldOptions is not defined. libprotobuf ERROR google/protobuf/descriptor.cc:2218] google.protobuf.EnumDescriptorProto.value: .google.protobuf.EnumValueDescriptorProto is not defined. libprotobuf ERROR google/protobuf/descriptor.cc:2218] google.protobuf.EnumDescriptorProto.options: .google.protobuf.EnumOptions is not defined. libprotobuf ERROR google/protobuf/descriptor.cc:2218] google.protobuf.EnumValueDescriptorProto.options: .google.protobuf.EnumValueOptions is not defined. libprotobuf ERROR google/protobuf/descriptor.cc:2218] google.protobuf.ServiceDescriptorProto.method: .google.protobuf.MethodDescriptorProto is not defined. libprotobuf ERROR google/protobuf/descriptor.cc:2218] google.protobuf.ServiceDescriptorProto.options: .google.protobuf.ServiceOptions is not defined. libprotobuf ERROR google/protobuf/descriptor.cc:2218] google.protobuf.MethodDescriptorProto.options: .google.protobuf.MethodOptions is not defined. libprotobuf ERROR google/protobuf/descriptor.cc:2218] google.protobuf.FileOptions.optimize_for: .google.protobuf.FileOptions.OptimizeMode is not defined. libprotobuf ERROR google/protobuf/descriptor.cc:2218] google.protobuf.FileOptions.uninterpreted_option: .google.protobuf.UninterpretedOption is not defined. libprotobuf ERROR google/protobuf/descriptor.cc:2218] google.protobuf.MessageOptions.uninterpreted_option: .google.protobuf.UninterpretedOption is not defined. libprotobuf ERROR google/protobuf/descriptor.cc:2218] google.protobuf.FieldOptions.ctype: .google.protobuf.FieldOptions.CType is not defined. libprotobuf ERROR google/protobuf/descriptor.cc:2218] google.protobuf.FieldOptions.uninterpreted_option: .google.protobuf.UninterpretedOption is not defined. libprotobuf ERROR google/protobuf/descriptor.cc:2218] google.protobuf.EnumOptions.uninterpreted_option: .google.protobuf.UninterpretedOption is not defined. libprotobuf ERROR google/protobuf/descriptor.cc:2218] google.protobuf.EnumValueOptions.uninterpreted_option: .google.protobuf.UninterpretedOption is not defined. libprotobuf ERROR google/protobuf/descriptor.cc:2218] google.protobuf.ServiceOptions.uninterpreted_option: .google.protobuf.UninterpretedOption is not defined. libprotobuf ERROR google/protobuf/descriptor.cc:2218] google.protobuf.MethodOptions.uninterpreted_option: .google.protobuf.UninterpretedOption is not defined. libprotobuf ERROR google/protobuf/descriptor.cc:2218] google.protobuf.UninterpretedOption.name: .google.protobuf.UninterpretedOption.NamePart is not defined. libprotobuf FATAL google/protobuf/descriptor.pb.cc:82] CHECK failed: file != NULL: gmake[2]: *** [unittest_proto_middleman] IOT/Abort trap (core dumped) Any suggestions? Thanks Regards, Vikram On Jul 13, 5:23 pm, Kenton Varda ken...@google.com wrote: And yes, I'd love a patch. :) On Mon, Jul 13, 2009 at 5:22 PM, Kenton Varda ken...@google.com wrote: google/protobuf/stubs/hash.h already contains some hacks for hash_map. To support unordered_map, all we'd have to do is add another hack there which defines hash_map to be a subclass of unordered_map. Subclassing effectively functions as a template typedef here. I would rather not replace the identifier hash_map with unordered_map in the actual code until the Google style guide rules on the issue. I suspect that Google code will go on using hash_map with a similar hack because updating our entire code base is just not worth the effort. On Mon, Jul 13, 2009 at 5:13 PM, Monty Taylor mord...@inaugust.comwrote: vikram wrote: I have found out that with new xlC versions like 8.X onwards hash_map like functionality is supported but different name as unordered_map. So it there any way you can to use this container without modifying much of the code. In the code hash_map is used in many places. So it needs to be replaced with unordered_map with xlC compiler on AIX. Please provide some idea. I was trying to do template typedef but seems like I can not have all typenames while doing that. I was actually just working on making an update to the m4 to detect unordered_map
Re: Compiling on AIX 5.3 using xlC 3.55 compiler
I have found out that with new xlC versions like 8.X onwards hash_map like functionality is supported but different name as unordered_map. So it there any way you can to use this container without modifying much of the code. In the code hash_map is used in many places. So it needs to be replaced with unordered_map with xlC compiler on AIX. Please provide some idea. I was trying to do template typedef but seems like I can not have all typenames while doing that. Vikram On Jul 1, 12:00 pm, Kenton Varda ken...@google.com wrote: Well, it looks like all of these are stuck in the same place -- in the same call to hash_map::find(). This would seem to indicate that your STL implementation is broken. It's also possible that the infinite loop is actually in protobuf code, and the only reason we see it always breaking in the same find() call is because that's the most expensive part of the loop. You could test this by breaking under gdb again, and then repeatedly typing finish to make it run to completion of the current function call. If it eventually gets back to protobuf code, then the problem is there, otherwise it's in the STL code. (Actually, I should have told you to do this originally, rather than the collect multiple stack traces idea...) On Tue, Jun 30, 2009 at 7:36 PM, vikram patilvik...@gmail.com wrote: Hey Kenton, This is compilation without STL implementation . I am assuming that if hash_map does not exist , google protocol buffer emulates hash_map. I am pasting 3-4 instances of stack where protoc is in infinite loop #0 0xd1cfdc60 in _Node::_Right__Q2_3std5_TreeXTQ2_3std12_Tmap_traitsXTQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__TQ3_6google8protobuf25FieldDescriptorProto_TypeTQ3_6google8protobuf4hashXTQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc___TQ2_3std9allocatorXTQ2_3std4pairXTCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__TQ3_6google8protobuf25FieldDescriptorProto_Type__SP0__FPQ3_3std9_Tree_nodXTQ2_3std12_Tmap_traitsXTQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__TQ3_6google8protobuf25FieldDescriptorProto_TypeTQ3_6google8protobuf4hashXTQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc___TQ2_3std9allocatorXTQ2_3std4pairXTCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__TQ3_6google8protobuf25FieldDescriptorProto_Type__SP0 (_P=0xf04ca4e0) at /usr/vacpp/include/xtree:154 #1 0xd1d1bbdc in _Lbound__Q2_3std5_TreeXTQ2_3std12_Tmap_traitsXTQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__TQ3_6google8protobuf25FieldDescriptorProto_TypeTQ3_6google8protobuf4hashXTQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc___TQ2_3std9allocatorXTQ2_3std4pairXTCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__TQ3_6google8protobuf25FieldDescriptorProto_Type__SP0__CFRCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__ (this=0xf04ca4e0, _...@0x2ffc) at /usr/vacpp/include/xtree.t:377 #2 0xd1d22878 in lower_bound__Q2_3std5_TreeXTQ2_3std12_Tmap_traitsXTQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__TQ3_6google8protobuf25FieldDescriptorProto_TypeTQ3_6google8protobuf4hashXTQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc___TQ2_3std9allocatorXTQ2_3std4pairXTCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__TQ3_6google8protobuf25FieldDescriptorProto_Type__SP0__CFRCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__ (this=0xf04ca4e0, __classretu...@0x2ff21d70, _...@0x2ffc) at /usr/ vacpp/include/xtree:377 #3 0xd1d28f34 in find__Q2_3std5_TreeXTQ2_3std12_Tmap_traitsXTQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__TQ3_6google8protobuf25FieldDescriptorProto_TypeTQ3_6google8protobuf4hashXTQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc___TQ2_3std9allocatorXTQ2_3std4pairXTCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__TQ3_6google8protobuf25FieldDescriptorProto_Type__SP0__CFRCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__ (this=0xf04ca4e0, __classretu...@0x2ff21dd0, _...@0x2ffc) at /usr/ vacpp/include/xtree:365 #4 0xd1d2fd34 in ParseType__Q4_6google8protobuf8compiler6ParserFPQ3_6google8protobuf25FieldDescriptorProto_TypePQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__ (this=0x2ff22278, type=0x2ff21e24, type_name=0x2ff21e28) at google/protobuf/compiler/ parser.cc:1000 #5 0xd1d31438 in ParseMessageField__Q4_6google8protobuf8compiler6ParserFPQ3_6google8protobuf20FieldDescriptorProtoPQ3_6google8protobuf16RepeatedPtrFieldXTQ3_6google8protobuf15DescriptorProto_ ( this=0x2ff22278, field=0x2000f918, messages=0x2000f808) at google/ protobuf/compiler/parser.cc:443 #6 0xd1d30f50
Re: Compiling on AIX 5.3 using xlC 3.55 compiler
-2.1.0/src/./google/protobuf/descriptor.pb.h, line 23.10: 1540-0836 (S) The #include file google/protobuf/extension_set.h is not found. /work/vpatil/protobuf-2.1.0/src/./google/protobuf/extension_set.h, line 47.10: 1540-0836 (S) The #include file google/protobuf/stubs/common.h is not found. /work/vpatil/protobuf-2.1.0/src/./google/protobuf/extension_set.h, line 48.10: 1540-0836 (S) The #include file google/protobuf/message.h is not found. /work/vpatil/protobuf-2.1.0/src/./google/protobuf/message.h, line 139.10: 1540-0836 (S) The #include file google/protobuf/stubs/common.h is not found. /usr/vacpp/bin/xlC_r: 1501-240 Previous errors were found when compiling tempinc/_tree.C Please share some insights regarding this Thanks Regards, Vikram On Jun 26, 6:00 pm, Kenton Varda ken...@google.com wrote: This isn't telling me much. Can you interrupt and continue a few times to get a few different stack traces, in order to find out what the common part of the trace is? This should allow us to determine which loop is failing to terminate. On Fri, Jun 26, 2009 at 2:49 PM, vikram patilvik...@gmail.com wrote: @Kentan I built with debug info and got following stack trace . location of compiler is at /usr/vacpp/bin if its not by default. #0 0xd1afa248 in __lt__3stdHcQ2_3std11char_traitsXTc_Q2_3std9allocatorXTc__RCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__RCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc_ (_...@0xc, _...@0x2ff2221c) at /usr/vacpp/include/string:134 #1 0xd1afa374 in __cl__Q3_6google8protobuf4hashXTQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc___CFRCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__RCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__ (this=0xf04ca4e0, a...@0xc, b...@0x2ff2221c) at ./google/protobuf/stubs/ hash.h:177 #2 0xd1d1bbc8 in _Lbound__Q2_3std5_TreeXTQ2_3std12_Tmap_traitsXTQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__TQ3_6google8protobuf25FieldDescriptorProto_TypeTQ3_6google8protobuf4hashXTQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc___TQ2_3std9allocatorXTQ2_3std4pairXTCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__TQ3_6google8protobuf25FieldDescriptorProto_Type__SP0__CFRCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__ (this=0xf04ca4e0, _...@0x2ff2221c) at /usr/vacpp/include/xtree.t:376 #3 0xd1d22878 in lower_bound__Q2_3std5_TreeXTQ2_3std12_Tmap_traitsXTQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__TQ3_6google8protobuf25FieldDescriptorProto_TypeTQ3_6google8protobuf4hashXTQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc___TQ2_3std9allocatorXTQ2_3std4pairXTCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__TQ3_6google8protobuf25FieldDescriptorProto_Type__SP0__CFRCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__ (this=0xf04ca4e0, __classretu...@0x2ff21e70, _...@0x2ff2221c) at /usr/ vacpp/include/xtree:377 #4 0xd1d28f34 in find__Q2_3std5_TreeXTQ2_3std12_Tmap_traitsXTQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__TQ3_6google8protobuf25FieldDescriptorProto_TypeTQ3_6google8protobuf4hashXTQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc___TQ2_3std9allocatorXTQ2_3std4pairXTCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__TQ3_6google8protobuf25FieldDescriptorProto_Type__SP0__CFRCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__ (this=0xf04ca4e0, __classretu...@0x2ff21ed0, _...@0x2ff2221c) at /usr/ vacpp/include/xtree:365 #5 0xd1d2fd34 in ParseType__Q4_6google8protobuf8compiler6ParserFPQ3_6google8protobuf25FieldDescriptorProto_TypePQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__ (this=0x2ff22268, type=0x2ff21f24, type_name=0x2ff21f28) at google/protobuf/compiler/ parser.cc:1000 #6 0xd1d31438 in ParseMessageField__Q4_6google8protobuf8compiler6ParserFPQ3_6google8protobuf20FieldDescriptorProtoPQ3_6google8protobuf16RepeatedPtrFieldXTQ3_6google8protobuf15DescriptorProto_ ( this=0x2ff22268, field=0x2000f538, messages=0x2000f458) at google/ protobuf/compiler/parser.cc:443 #7 0xd1d30f50 in google::protobuf::compiler::Parser::ParseMessageStatement (this=0x2ff22268, message=0x2000f3f8) at google/protobuf/compiler/ parser.cc:428 #8 0xd1d310c4 in google::protobuf::compiler::Parser::ParseMessageBlock (this=0x2ff22268, message=0x2000f3f8) at google/protobuf/compiler/ parser.cc:402 #9 0xd1d30c80 in google::protobuf::compiler::Parser::ParseMessageDefinition (this=0x2ff22268, message=0x2000f3f8) at google/protobuf/compiler/ parser.cc:389 #10 0xd1d3250c in google::protobuf::compiler::Parser::ParseTopLevelStatement (this=0x2ff22268, file=0x2ff22310
Re: Compiling on AIX 5.3 using xlC 3.55 compiler
allocatorXTc___TQ2_3std9allocatorXTQ2_3std4pairXTCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__TQ3_6google8protobuf25FieldDescriptorProto_Type__SP0__CFRCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__ (this=0xf04ca4e0, __classretu...@0x2ff21d70, _...@0x2ffc) at /usr/ vacpp/include/xtree:377 #4 0xd1d28f34 in find__Q2_3std5_TreeXTQ2_3std12_Tmap_traitsXTQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__TQ3_6google8protobuf25FieldDescriptorProto_TypeTQ3_6google8protobuf4hashXTQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc___TQ2_3std9allocatorXTQ2_3std4pairXTCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__TQ3_6google8protobuf25FieldDescriptorProto_Type__SP0__CFRCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__ (this=0xf04ca4e0, __classretu...@0x2ff21dd0, _...@0x2ffc) at /usr/ vacpp/include/xtree:365 #5 0xd1d2fd34 in ParseType__Q4_6google8protobuf8compiler6ParserFPQ3_6google8protobuf25FieldDescriptorProto_TypePQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__ (this=0x2ff22278, type=0x2ff21e24, type_name=0x2ff21e28) at google/protobuf/compiler/ parser.cc:1000 #6 0xd1d31438 in ParseMessageField__Q4_6google8protobuf8compiler6ParserFPQ3_6google8protobuf20FieldDescriptorProtoPQ3_6google8protobuf16RepeatedPtrFieldXTQ3_6google8protobuf15DescriptorProto_ ( this=0x2ff22278, field=0x2000f918, messages=0x2000f808) at google/ protobuf/compiler/parser.cc:443 #7 0xd1d30f50 in google::protobuf::compiler::Parser::ParseMessageStatement (this=0x2ff22278, message=0x2000f7a8) at google/protobuf/compiler/ parser.cc:428 #8 0xd1d310c4 in google::protobuf::compiler::Parser::ParseMessageBlock (this=0x2ff22278, message=0x2000f7a8) at google/protobuf/compiler/ parser.cc:402 #9 0xd1d30c80 in google::protobuf::compiler::Parser::ParseMessageDefinition (this=0x2ff22278, message=0x2000f7a8) at google/protobuf/compiler/ parser.cc:389 #10 0xd1d30e28 in google::protobuf::compiler::Parser::ParseMessageStatement (this=0x2ff22278, message=0x2000f668) at google/protobuf/compiler/ parser.cc:417 #11 0xd1d310c4 in google::protobuf::compiler::Parser::ParseMessageBlock (this=0x2ff22278, message=0x2000f668) at google/protobuf/compiler/ parser.cc:402 #12 0xd1d30c80 in google::protobuf::compiler::Parser::ParseMessageDefinition (this=0x2ff22278, message=0x2000f668) at google/protobuf/compiler/ parser.cc:389 #13 0xd1d3250c in google::protobuf::compiler::Parser::ParseTopLevelStatement (this=0x2ff22278, file=0x2ff22320) at google/protobuf/compiler/ parser.cc:362 #14 0xd1d32c80 in google::protobuf::compiler::Parser::Parse (this=0x2ff22278, input=0x2ff8, file=0x2ff22320) at google/ protobuf/compiler/parser.cc:321 #15 0xd1d4965c in FindFileByName__Q4_6google8protobuf8compiler28SourceTreeDescriptorDatabaseFRCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc (this=0x2ff22548, filena...@0x2000bce8, output=0x2ff22320) at google/protobuf/compiler/importer.cc:145 #16 0xd1b4a4f0 in TryFindFileInFallbackDatabase__Q3_6google8protobuf14DescriptorPoolCFRCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__ (this=0x2ff2256c, na...@0x2000bce8) at google/protobuf/descriptor.cc:1230 #17 0xd1b4a844 in FindFileByName__Q3_6google8protobuf14DescriptorPoolCFRCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__ (this=0x2ff2256c, na...@0x2000bce8) at google/protobuf/descriptor.cc:875 #18 0xd1d47ad4 in Import__Q4_6google8protobuf8compiler8ImporterFRCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__ (this=0x2ff22548, filena...@0x2000bce8) at google/protobuf/compiler/importer.cc:194 #19 0xd1757ea0 in google::protobuf::compiler::CommandLineInterface::Run (this=0x2ff22750, argc=3, argv=0x2ff228f0) at google/protobuf/compiler/ command_line_interface.cc:352 #20 0x10002894 in main (argc=3, argv=0x2ff228f0) at google/protobuf/ compiler/main.cc:59 #21 0x11ec in __start () Vikram On Jun 30, 7:26 pm, Kenton Varda ken...@google.com wrote: This looks like a problem with the STL implementation. Sorry, I don't know what to do about this. On Tue, Jun 30, 2009 at 5:32 PM, vikram patilvik...@gmail.com wrote: My attempt to use default hash_map implementation in source leads to infinite loop. So I tried to links source with STLport 4.6.1 version for AIX. For XLC i provided tempinc option to create default directory for template instantiation. But I am not able to compile it. /net/bld9-ibm/XYZ01/build/tools/Development/STLport/AIX/STLport-4.6.1/ stlport/stl/_alloc.h, line 60.12: 1540-0836 (S) The #include file stl/_new.h is not found. /net/bld9-ibm/XYZ01/build/tools/Development/STLport/AIX/STLport-4.6.1/ stlport/stl/_alloc.h, line 64.11: 1540-0836 (S) The #include file stl/_threads.h is not found. /net/bld9-ibm/XYZ01/build/tools/Development/STLport/AIX/STLport-4.6.1/ stlport/stl/_alloc.h, line 68.11: 1540-0836 (S) The #include file stl/_construct.h is not found. /net/bld9-ibm/XYZ01/build/tools
Re: Compiling on AIX 5.3 using xlC 3.55 compiler
::CommandLineInterface::Run (this=0x2ff22740, argc=3, argv=0x2ff228e0) at google/protobuf/compiler/ command_line_interface.cc:352 #17 0x10002894 in main (argc=3, argv=0x2ff228e0) at google/protobuf/ compiler/main.cc:59 #18 0x11ec in __start () Vikram On Jun 26, 2:14 pm, Kenton Varda ken...@google.com wrote: Can you do a build with debug info to get line numbers? On Fri, Jun 26, 2009 at 1:29 PM, vikram patilvik...@gmail.com wrote: bash-3.00$ gdb src/.libs/lt-protoc GNU gdb 5.1.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as powerpc-ibm-aix4.3.2.0...(no debugging symbols found)... (gdb) run CHANGES.txt Makefile.in config.h.in depcomp java src CONTRIBUTORS.txt README.txt config.log editors libtool stamp-h1 COPYING.txt aclocal.m4 config.status examples ltmain.sh vsprojects INSTALL.txt autogen.sh config.sub generate_descriptor_proto.sh m4 warning.txt Makefile config.guess configure gtest missing Makefile.am config.h configure.ac install-sh python (gdb) run CHANGES.txt Makefile.in config.h.in depcomp java src CONTRIBUTORS.txt README.txt config.log editors libtool stamp-h1 COPYING.txt aclocal.m4 config.status examples ltmain.sh vsprojects INSTALL.txt autogen.sh config.sub generate_descriptor_proto.sh m4 warning.txt Makefile config.guess configure gtest missing Makefile.am config.h configure.ac install-sh python (gdb) run src/g generated_message_reflection.lo google gzip_stream.lo (gdb) run src/google/protobuf/test test.proto test1.proto test_util.cc test_util.h testdata testing (gdb) run src/google/protobuf/test.proto --cpp_out=. Starting program: /work/vpatil/protobuf-2.1.0/src/.libs/lt-protoc src/ google/protobuf/test.proto --cpp_out=. *** HOST: Undefined variable. (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Program received signal SIGINT, Interrupt. 0xd1cfe90c in __384 () from /work/vpatil/protobuf-2.1.0/src/.libs/ libprotobuf.a(libprotobuf.so.4) (gdb) backtrace #0 0xd1cfe90c in __384 () from /work/vpatil/protobuf-2.1.0/src/.libs/ libprotobuf.a(libprotobuf.so.4) #1 0xd1cfe900 in __384 () from /work/vpatil/protobuf-2.1.0/src/.libs/ libprotobuf.a(libprotobuf.so.4) #2 0xd1d056c0 in __384 () from /work/vpatil/protobuf-2.1.0/src/.libs/ libprotobuf.a(libprotobuf.so.4) #3 0xd1d0bd48 in google::protobuf::compiler::SourceLocationTable::__ct () from /work/ vpatil/protobuf-2.1.0/src/.libs/libprotobuf.a(libprotobuf.so.4) #4 0xd1d128b8 in ParseType__Q4_6google8protobuf8compiler6ParserFPQ3_6google8protobuf25FieldDescriptorProto_TypePQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__ () from /work/vpatil/protobuf-2.1.0/src/.libs/libprotobuf.a (libprotobuf.so.4) #5 0xd1d13f64 in ParseMessageField__Q4_6google8protobuf8compiler6ParserFPQ3_6google8protobuf20FieldDescriptorProtoPQ3_6google8protobuf16RepeatedPtrFieldXTQ3_6google8protobuf15DescriptorProto_ () from /work/vpatil/protobuf-2.1.0/src/.libs/libprotobuf.a (libprotobuf.so.4) #6 0xd1d13a8c in google::protobuf::compiler::Parser::ParseMessageStatement () from / work/vpatil/protobuf-2.1.0/src/.libs/libprotobuf.a(libprotobuf.so.4) #7 0xd1d13bfc in google::protobuf::compiler::Parser::ParseMessageBlock () from /work/ vpatil/protobuf-2.1.0/src/.libs/libprotobuf.a(libprotobuf.so.4) #8 0xd1d137c4 in google::protobuf::compiler::Parser::ParseMessageDefinition () from / work/vpatil/protobuf-2.1.0/src/.libs/libprotobuf.a(libprotobuf.so.4) #9 0xd1d14ffc in google::protobuf::compiler::Parser::ParseTopLevelStatement () from
Re: Sun Studio 11
I am using CC: Sun C++ 5.9 compiler to compile on Solaris. I was able
to compile source but tests are failing.
I need some help here about libtool
/bin/bash ./libtool --tag=CXX--mode=link CC -g-o lib/
libgtest.la -rpath /usr/local/lib src/gtest.lo src/gtest-death-
test.lo src/gtest-filepath.lo src/gtest-port.lo src/gtest-test-
part.lo src/gtest-typed-test.lo
libtool: link: rm -fr lib/.libs/libgtest.so lib/.libs/libgtest.so.0
libtool: link: (cd lib/.libs rm -f libgtest.so.0 ln -s
libgtest.so.0.0.0 libgtest.so.0)
libtool: link: (cd lib/.libs rm -f libgtest.so ln -s
libgtest.so.0.0.0 libgtest.so)
libtool: link: ar cru lib/.libs/libgtest.a src/gtest.o src/gtest-
death-test.o src/gtest-filepath.o src/gtest-port.o src/gtest-test-
part.o src/gtest-typed-test.o
ar: cannot open src/gtest.o
No such file or directory
ar: cannot open src/gtest-death-test.o
No such file or directory
ar: cannot open src/gtest-filepath.o
No such file or directory
ar: cannot open src/gtest-port.o
No such file or directory
ar: cannot open src/gtest-test-part.o
No such file or directory
ar: cannot open src/gtest-typed-test.o
No such file or directory
ar: src/gtest.o not found
ar: src/gtest-death-test.o not found
ar: src/gtest-filepath.o not found
ar: src/gtest-port.o not found
ar: src/gtest-test-part.o not found
ar: src/gtest-typed-test.o not found
All object files are created in the same directory as Makefile and in
src/.libs/ directory . While libtool looks for these files in
src directory. I am new too libtool so I am not able to solve the
problem.
On Jun 22, 4:38 pm, vikram patilvik...@gmail.com wrote:
I am trying out what changes he suggested uptil now I am able to
compile but gtests are failing. I will update discussion once I am
able to find out whats going with gtests.
Vikram
On Jun 22, 4:34 pm, Kenton Varda ken...@google.com wrote:
I haven't heard from the patch author since my previous mail. :/
On Mon, Jun 22, 2009 at 4:06 PM, vikram patilvik...@gmail.com wrote:
Can somebody point out when this patch will be included in source?
I am trying to do compilation on Solaris 10 but right now I am getting
errors as mentioned in this post.
Vikram
On Jun 4, 1:42 pm, Kenton Varda ken...@google.com wrote:
Thanks for the patch!
It looks like you were using the examples as a test. Running make
check
in the top directory will run a much better suite of tests -- do they
pass?
Assuming it does work, can you re-send that patch as an attachment (it
looks
like it has been mangled), or even send it to me via
codereview.appspot.com?
Also, for me to submit it you'll need to sign the contributor license
agreement:
http://code.google.com/legal/individual-cla-v1.0.html--ifyou own
copyright on this patchhttp://
code.google.com/legal/corporate-cla-v1.0.html-- if your employer
does
On Wed, Jun 3, 2009 at 10:53 PM, bmcarnes_proto...@oddren.com wrote:
Probably not. LibCstd isn't complete enough for protobuf.
I was able to get protobuf 2.1.0 to work well under Sun Studio 11,
using libCstd, with a few patches. Works well enough to compile and
run the add_person_cpp/list_people_cpp examples.
I include the build instructions and patch set below Also included
are patches to the examples makefile to test it out.
Apply below patchset first against protobuf 2.1.0
$ CXX=CC CC=cc ./configure --disable-shared
$ make
$ cd examples
$ make cpp
$ ./add_person_cpp addressbook.test
(enter a test record)
$ ./list_people_cpp addressbook.test
(test record is displayed correctly)
$ ldd list_people_cpp (or ldd add_person_cpp )
libpthread.so.1 = /lib/libpthread.so.1
libCstd.so.1 = /usr/lib/libCstd.so.1
libCrun.so.1 = /usr/lib/libCrun.so.1
libm.so.2 = /lib/libm.so.2
libc.so.1 = /lib/libc.so.1
Index: src/google/protobuf/repeated_field.h
===
--- src/google/protobuf/repeated_field.h (revision 2)
+++ src/google/protobuf/repeated_field.h (working copy)
@@ -69,7 +69,7 @@
class LIBPROTOBUF_EXPORT GenericRepeatedField {
public:
inline GenericRepeatedField() {}
-#if defined(__DECCXX) defined(__osf__)
+#if defined(__SUNPRO_CC) || defined(__DECCXX) defined(__osf__)
// HP C++ on Tru64 has trouble when this is not defined inline.
virtual ~GenericRepeatedField() {}
#else
@@ -548,7 +548,7 @@
current_size_ = 0;
}
-#if defined(__DECCXX) defined(__osf__)
+#if defined(__SUNPRO_CC) || defined(__DECCXX) defined(__osf__)
// HP C++ on Tru64 has trouble when this is not defined inline.
template
inline void RepeatedPtrFieldstring::Clear() {
Index: src/google/protobuf
Re: Sun Studio 11
I am using 2.1.0 only.
On Jun 24, 12:26 pm, Kenton Varda ken...@google.com wrote:
The list of files there suggest that you're using protobuf 2.0.3 or earlier.
Have you tried 2.1.0?
On Wed, Jun 24, 2009 at 11:54 AM, vikram patilvik...@gmail.com wrote:
I am using CC: Sun C++ 5.9 compiler to compile on Solaris. I was able
to compile source but tests are failing.
I need some help here about libtool
/bin/bash ./libtool --tag=CXX --mode=link CC -g -o lib/
libgtest.la -rpath /usr/local/lib src/gtest.lo src/gtest-death-
test.lo src/gtest-filepath.lo src/gtest-port.lo src/gtest-test-
part.lo src/gtest-typed-test.lo
libtool: link: rm -fr lib/.libs/libgtest.so lib/.libs/libgtest.so.0
libtool: link: (cd lib/.libs rm -f libgtest.so.0 ln -s
libgtest.so.0.0.0 libgtest.so.0)
libtool: link: (cd lib/.libs rm -f libgtest.so ln -s
libgtest.so.0.0.0 libgtest.so)
libtool: link: ar cru lib/.libs/libgtest.a src/gtest.o src/gtest-
death-test.o src/gtest-filepath.o src/gtest-port.o src/gtest-test-
part.o src/gtest-typed-test.o
ar: cannot open src/gtest.o
No such file or directory
ar: cannot open src/gtest-death-test.o
No such file or directory
ar: cannot open src/gtest-filepath.o
No such file or directory
ar: cannot open src/gtest-port.o
No such file or directory
ar: cannot open src/gtest-test-part.o
No such file or directory
ar: cannot open src/gtest-typed-test.o
No such file or directory
ar: src/gtest.o not found
ar: src/gtest-death-test.o not found
ar: src/gtest-filepath.o not found
ar: src/gtest-port.o not found
ar: src/gtest-test-part.o not found
ar: src/gtest-typed-test.o not found
All object files are created in the same directory as Makefile and in
src/.libs/ directory . While libtool looks for these files in
src directory. I am new too libtool so I am not able to solve the
problem.
On Jun 22, 4:38 pm, vikram patilvik...@gmail.com wrote:
I am trying out what changes he suggested uptil now I am able to
compile but gtests are failing. I will update discussion once I am
able to find out whats going with gtests.
Vikram
On Jun 22, 4:34 pm, Kenton Varda ken...@google.com wrote:
I haven't heard from the patch author since my previous mail. :/
On Mon, Jun 22, 2009 at 4:06 PM, vikram patilvik...@gmail.com wrote:
Can somebody point out when this patch will be included in source?
I am trying to do compilation on Solaris 10 but right now I am
getting
errors as mentioned in this post.
Vikram
On Jun 4, 1:42 pm, Kenton Varda ken...@google.com wrote:
Thanks for the patch!
It looks like you were using the examples as a test. Running make
check
in the top directory will run a much better suite of tests -- do
they
pass?
Assuming it does work, can you re-send that patch as an attachment
(it
looks
like it has been mangled), or even send it to me via
codereview.appspot.com?
Also, for me to submit it you'll need to sign the contributor
license
agreement:
http://code.google.com/legal/individual-cla-v1.0.html--ifyouown
copyright on this patchhttp://
code.google.com/legal/corporate-cla-v1.0.html-- if your employer
does
On Wed, Jun 3, 2009 at 10:53 PM, bmcarnes_proto...@oddren.com
wrote:
Probably not. LibCstd isn't complete enough for protobuf.
I was able to get protobuf 2.1.0 to work well under Sun Studio
11,
using libCstd, with a few patches. Works well enough to compile
and
run the add_person_cpp/list_people_cpp examples.
I include the build instructions and patch set below Also
included
are patches to the examples makefile to test it out.
Apply below patchset first against protobuf 2.1.0
$ CXX=CC CC=cc ./configure --disable-shared
$ make
$ cd examples
$ make cpp
$ ./add_person_cpp addressbook.test
(enter a test record)
$ ./list_people_cpp addressbook.test
(test record is displayed correctly)
$ ldd list_people_cpp (or ldd add_person_cpp )
libpthread.so.1 = /lib/libpthread.so.1
libCstd.so.1 = /usr/lib/libCstd.so.1
libCrun.so.1 = /usr/lib/libCrun.so.1
libm.so.2 = /lib/libm.so.2
libc.so.1 = /lib/libc.so.1
Index: src/google/protobuf/repeated_field.h
===
--- src/google/protobuf/repeated_field.h (revision 2)
+++ src/google/protobuf/repeated_field.h (working copy)
@@ -69,7 +69,7 @@
class LIBPROTOBUF_EXPORT GenericRepeatedField {
public:
inline GenericRepeatedField() {}
-#if defined(__DECCXX) defined(__osf__)
+#if defined(__SUNPRO_CC) || defined(__DECCXX)
defined(__osf__)
// HP C
Re: Sun Studio 11
no . I wanted to compile it . But have you got those tests working . I
am not able to compile those yet.
On Jun 24, 12:48 pm, Monty Taylor mo...@inaugust.com wrote:
I'm hacking on a patch to make 2.1.0 work properly on my Sun Studio set
up as we speak. Was there something more specific you wanted from it
than just compiling?
vikram wrote:
I am using 2.1.0 only.
On Jun 24, 12:26 pm, Kenton Varda ken...@google.com wrote:
The list of files there suggest that you're using protobuf 2.0.3 or
earlier.
Have you tried 2.1.0?
On Wed, Jun 24, 2009 at 11:54 AM, vikram patilvik...@gmail.com wrote:
I am using CC: Sun C++ 5.9 compiler to compile on Solaris. I was able
to compile source but tests are failing.
I need some help here about libtool
/bin/bash ./libtool --tag=CXX --mode=link CC -g -o lib/
libgtest.la -rpath /usr/local/lib src/gtest.lo src/gtest-death-
test.lo src/gtest-filepath.lo src/gtest-port.lo src/gtest-test-
part.lo src/gtest-typed-test.lo
libtool: link: rm -fr lib/.libs/libgtest.so lib/.libs/libgtest.so.0
libtool: link: (cd lib/.libs rm -f libgtest.so.0 ln -s
libgtest.so.0.0.0 libgtest.so.0)
libtool: link: (cd lib/.libs rm -f libgtest.so ln -s
libgtest.so.0.0.0 libgtest.so)
libtool: link: ar cru lib/.libs/libgtest.a src/gtest.o src/gtest-
death-test.o src/gtest-filepath.o src/gtest-port.o src/gtest-test-
part.o src/gtest-typed-test.o
ar: cannot open src/gtest.o
No such file or directory
ar: cannot open src/gtest-death-test.o
No such file or directory
ar: cannot open src/gtest-filepath.o
No such file or directory
ar: cannot open src/gtest-port.o
No such file or directory
ar: cannot open src/gtest-test-part.o
No such file or directory
ar: cannot open src/gtest-typed-test.o
No such file or directory
ar: src/gtest.o not found
ar: src/gtest-death-test.o not found
ar: src/gtest-filepath.o not found
ar: src/gtest-port.o not found
ar: src/gtest-test-part.o not found
ar: src/gtest-typed-test.o not found
All object files are created in the same directory as Makefile and in
src/.libs/ directory . While libtool looks for these files in
src directory. I am new too libtool so I am not able to solve the
problem.
On Jun 22, 4:38 pm, vikram patilvik...@gmail.com wrote:
I am trying out what changes he suggested uptil now I am able to
compile but gtests are failing. I will update discussion once I am
able to find out whats going with gtests.
Vikram
On Jun 22, 4:34 pm, Kenton Varda ken...@google.com wrote:
I haven't heard from the patch author since my previous mail. :/
On Mon, Jun 22, 2009 at 4:06 PM, vikram patilvik...@gmail.com wrote:
Can somebody point out when this patch will be included in source?
I am trying to do compilation on Solaris 10 but right now I am
getting
errors as mentioned in this post.
Vikram
On Jun 4, 1:42 pm, Kenton Varda ken...@google.com wrote:
Thanks for the patch!
It looks like you were using the examples as a test. Running make
check
in the top directory will run a much better suite of tests -- do
they
pass?
Assuming it does work, can you re-send that patch as an attachment
(it
looks
like it has been mangled), or even send it to me via
codereview.appspot.com?
Also, for me to submit it you'll need to sign the contributor
license
agreement:
http://code.google.com/legal/individual-cla-v1.0.html--ifyouown
copyright on this patchhttp://
code.google.com/legal/corporate-cla-v1.0.html-- if your employer
does
On Wed, Jun 3, 2009 at 10:53 PM, bmcarnes_proto...@oddren.com
wrote:
Probably not. LibCstd isn't complete enough for protobuf.
I was able to get protobuf 2.1.0 to work well under Sun Studio
11,
using libCstd, with a few patches. Works well enough to compile
and
run the add_person_cpp/list_people_cpp examples.
I include the build instructions and patch set below Also
included
are patches to the examples makefile to test it out.
Apply below patchset first against protobuf 2.1.0
$ CXX=CC CC=cc ./configure --disable-shared
$ make
$ cd examples
$ make cpp
$ ./add_person_cpp addressbook.test
(enter a test record)
$ ./list_people_cpp addressbook.test
(test record is displayed correctly)
$ ldd list_people_cpp (or ldd add_person_cpp )
libpthread.so.1 = /lib/libpthread.so.1
libCstd.so.1 = /usr/lib/libCstd.so.1
libCrun.so.1 = /usr/lib/libCrun.so.1
libm.so.2 = /lib/libm.so.2
libc.so.1 = /lib/libc.so.1
Index: src/google/protobuf/repeated_field.h
===
--- src/google/protobuf/repeated_field.h (revision 2)
+++ src/google/protobuf/repeated_field.h (working copy)
@@ -69,7 +69,7 @@
class LIBPROTOBUF_EXPORT GenericRepeatedField {
public:
inline GenericRepeatedField() {}
-#if defined(__DECCXX
Re: Sun Studio 11
Monty Main source compile but when I do ' make check ' , it fails with the errors I posted previously. Vikram On Jun 24, 12:59 pm, Monty Taylor mo...@inaugust.com wrote: Try this patch, see if it helps you. I've got another one coming, but I'm interested to know if this solves your current problem. You'll probably want to do a make clean ... Monty vikram wrote: no . I wanted to compile it . But have you got those tests working . I am not able to compile those yet. On Jun 24, 12:48 pm, Monty Taylor mo...@inaugust.com wrote: I'm hacking on a patch to make 2.1.0 work properly on my Sun Studio set up as we speak. Was there something more specific you wanted from it than just compiling? vikram wrote: I am using 2.1.0 only. On Jun 24, 12:26 pm, Kenton Varda ken...@google.com wrote: The list of files there suggest that you're using protobuf 2.0.3 or earlier. Have you tried 2.1.0? On Wed, Jun 24, 2009 at 11:54 AM, vikram patilvik...@gmail.com wrote: I am using CC: Sun C++ 5.9 compiler to compile on Solaris. I was able to compile source but tests are failing. I need some help here about libtool /bin/bash ./libtool --tag=CXX --mode=link CC -g -o lib/ libgtest.la -rpath /usr/local/lib src/gtest.lo src/gtest-death- test.lo src/gtest-filepath.lo src/gtest-port.lo src/gtest-test- part.lo src/gtest-typed-test.lo libtool: link: rm -fr lib/.libs/libgtest.so lib/.libs/libgtest.so.0 libtool: link: (cd lib/.libs rm -f libgtest.so.0 ln -s libgtest.so.0.0.0 libgtest.so.0) libtool: link: (cd lib/.libs rm -f libgtest.so ln -s libgtest.so.0.0.0 libgtest.so) libtool: link: ar cru lib/.libs/libgtest.a src/gtest.o src/gtest- death-test.o src/gtest-filepath.o src/gtest-port.o src/gtest-test- part.o src/gtest-typed-test.o ar: cannot open src/gtest.o No such file or directory ar: cannot open src/gtest-death-test.o No such file or directory ar: cannot open src/gtest-filepath.o No such file or directory ar: cannot open src/gtest-port.o No such file or directory ar: cannot open src/gtest-test-part.o No such file or directory ar: cannot open src/gtest-typed-test.o No such file or directory ar: src/gtest.o not found ar: src/gtest-death-test.o not found ar: src/gtest-filepath.o not found ar: src/gtest-port.o not found ar: src/gtest-test-part.o not found ar: src/gtest-typed-test.o not found All object files are created in the same directory as Makefile and in src/.libs/ directory . While libtool looks for these files in src directory. I am new too libtool so I am not able to solve the problem. On Jun 22, 4:38 pm, vikram patilvik...@gmail.com wrote: I am trying out what changes he suggested uptil now I am able to compile but gtests are failing. I will update discussion once I am able to find out whats going with gtests. Vikram On Jun 22, 4:34 pm, Kenton Varda ken...@google.com wrote: I haven't heard from the patch author since my previous mail. :/ On Mon, Jun 22, 2009 at 4:06 PM, vikram patilvik...@gmail.com wrote: Can somebody point out when this patch will be included in source? I am trying to do compilation on Solaris 10 but right now I am getting errors as mentioned in this post. Vikram On Jun 4, 1:42 pm, Kenton Varda ken...@google.com wrote: Thanks for the patch! It looks like you were using the examples as a test. Running make check in the top directory will run a much better suite of tests -- do they pass? Assuming it does work, can you re-send that patch as an attachment (it looks like it has been mangled), or even send it to me via codereview.appspot.com? Also, for me to submit it you'll need to sign the contributor license agreement: http://code.google.com/legal/individual-cla-v1.0.html--ifyouown copyright on this patchhttp:// code.google.com/legal/corporate-cla-v1.0.html-- if your employer does On Wed, Jun 3, 2009 at 10:53 PM, bmcarnes_proto...@oddren.com wrote: Probably not. LibCstd isn't complete enough for protobuf. I was able to get protobuf 2.1.0 to work well under Sun Studio 11, using libCstd, with a few patches. Works well enough to compile and run the add_person_cpp/list_people_cpp examples. I include the build instructions and patch set below Also included are patches to the examples makefile to test it out. Apply below patchset first against protobuf 2.1.0 $ CXX=CC CC=cc ./configure --disable-shared $ make $ cd examples $ make cpp $ ./add_person_cpp addressbook.test (enter a test record) $ ./list_people_cpp addressbook.test (test record is displayed correctly) $ ldd list_people_cpp (or ldd add_person_cpp ) libpthread.so.1 = /lib/libpthread.so.1 libCstd.so.1 = /usr/lib/libCstd.so.1 libCrun.so.1 = /usr/lib/libCrun.so.1 libm.so.2 = /lib/libm.so.2 libc.so.1 = /lib/libc.so.1
Re: Sun Studio 11
@Monty I followed your steps but make check still fails with following errors make check Making check in . make check-local Making lib/libgtest.a lib/libgtest_main.a in gtest `lib/libgtest.la' is up to date. `lib/libgtest_main.la' is up to date. Making check in src make check-am make protobuf-test protobuf-lazy-descriptor-test zcgzip zcgunzip source='google/protobuf/compiler/cpp/cpp_unittest.cc' object='protobuf_test-cpp_unittest.o' libtool=no \ DEPDIR=.deps depmode=none /bin/bash ../depcomp \ CC -DHAVE_CONFIG_H -I. -I.. -I../gtest/include -I../gtest/ include -D_REENTRANT -g -DNDEBUG -c -o protobuf_test-cpp_unittest.o `test -f 'google/protobuf/compiler/cpp/cpp_unittest.cc' || echo './'`google/protobuf/compiler/cpp/cpp_unittest.cc ./google/protobuf/descriptor.h, line 324: Warning: Identifier expected instead of }. ./google/protobuf/descriptor.h, line 343: Warning: Identifier expected instead of }. ./google/protobuf/descriptor.h, line 354: Warning: Identifier expected instead of }. ./google/protobuf/io/tokenizer.h, line 107: Warning: Identifier expected instead of }. google/protobuf/compiler/cpp/cpp_unittest.cc, line 120: Warning: A non-POD object of type std::string passed as a variable argument to function testing::internal::IsNullLiteralHelper(...). google/protobuf/compiler/cpp/cpp_unittest.cc, line 442: Error: TestAllTypes is not defined. google/protobuf/compiler/cpp/cpp_unittest.cc, line 457: Error: TestPackedTypes is not defined. google/protobuf/compiler/cpp/cpp_unittest.cc, line 475: Error: TestAllTypes is not defined. google/protobuf/compiler/cpp/cpp_unittest.cc, line 494: Error: TestPackedTypes is not defined. 4 Error(s) and 5 Warning(s) detected. *** Error code 4 make: Fatal error: Command failed for target `protobuf_test- cpp_unittest.o' Current working directory /work/vpatil/protobuf-2.1.0/src *** Error code 1 make: Fatal error: Command failed for target `check-am' Current working directory /work/vpatil/protobuf-2.1.0/src *** Error code 1 make: Fatal error: Command failed for target `check' Current working directory /work/vpatil/protobuf-2.1.0/src *** Error code 1 The following command caused the error: failcom='exit 1'; \ for f in x $MAKEFLAGS; do \ case $f in \ *=* | --[!k]*);; \ *k*) failcom='fail=yes';; \ esac; \ done; \ dot_seen=no; \ target=`echo check-recursive | sed s/-recursive//`; \ list='. src'; for subdir in $list; do \ echo Making $target in $subdir; \ if test $subdir = .; then \ dot_seen=yes; \ local_target=$target-am; \ else \ local_target=$target; \ fi; \ (cd $subdir make $local_target) \ || eval $failcom; \ done; \ if test $dot_seen = no; then \ make $target-am || exit 1; \ fi; test -z $fail make: Fatal error: Command failed for target `check-recursive' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Sun Studio 11
I was finally able to compile it correctly and evaluate its correctness using tests. Kenton, Is there anything else I need to evaluate before using compiler and binaries. I can provide patch now if its needed. I am also going to try same procedure on AIX too . Is there any other precautions I needed to take before compiling on AIX? If it goes through without problem, I can provide patch which can include changes for both Solaris and AIX . Vikram On Jun 24, 1:40 pm, vikram patilvik...@gmail.com wrote: @Monty I followed your steps but make check still fails with following errors make check Making check in . make check-local Making lib/libgtest.a lib/libgtest_main.a in gtest `lib/libgtest.la' is up to date. `lib/libgtest_main.la' is up to date. Making check in src make check-am make protobuf-test protobuf-lazy-descriptor-test zcgzip zcgunzip source='google/protobuf/compiler/cpp/cpp_unittest.cc' object='protobuf_test-cpp_unittest.o' libtool=no \ DEPDIR=.deps depmode=none /bin/bash ../depcomp \ CC -DHAVE_CONFIG_H -I. -I.. -I../gtest/include -I../gtest/ include -D_REENTRANT -g -DNDEBUG -c -o protobuf_test-cpp_unittest.o `test -f 'google/protobuf/compiler/cpp/cpp_unittest.cc' || echo './'`google/protobuf/compiler/cpp/cpp_unittest.cc ./google/protobuf/descriptor.h, line 324: Warning: Identifier expected instead of }. ./google/protobuf/descriptor.h, line 343: Warning: Identifier expected instead of }. ./google/protobuf/descriptor.h, line 354: Warning: Identifier expected instead of }. ./google/protobuf/io/tokenizer.h, line 107: Warning: Identifier expected instead of }. google/protobuf/compiler/cpp/cpp_unittest.cc, line 120: Warning: A non-POD object of type std::string passed as a variable argument to function testing::internal::IsNullLiteralHelper(...). google/protobuf/compiler/cpp/cpp_unittest.cc, line 442: Error: TestAllTypes is not defined. google/protobuf/compiler/cpp/cpp_unittest.cc, line 457: Error: TestPackedTypes is not defined. google/protobuf/compiler/cpp/cpp_unittest.cc, line 475: Error: TestAllTypes is not defined. google/protobuf/compiler/cpp/cpp_unittest.cc, line 494: Error: TestPackedTypes is not defined. 4 Error(s) and 5 Warning(s) detected. *** Error code 4 make: Fatal error: Command failed for target `protobuf_test- cpp_unittest.o' Current working directory /work/vpatil/protobuf-2.1.0/src *** Error code 1 make: Fatal error: Command failed for target `check-am' Current working directory /work/vpatil/protobuf-2.1.0/src *** Error code 1 make: Fatal error: Command failed for target `check' Current working directory /work/vpatil/protobuf-2.1.0/src *** Error code 1 The following command caused the error: failcom='exit 1'; \ for f in x $MAKEFLAGS; do \ case $f in \ *=* | --[!k]*);; \ *k*) failcom='fail=yes';; \ esac; \ done; \ dot_seen=no; \ target=`echo check-recursive | sed s/-recursive//`; \ list='. src'; for subdir in $list; do \ echo Making $target in $subdir; \ if test $subdir = .; then \ dot_seen=yes; \ local_target=$target-am; \ else \ local_target=$target; \ fi; \ (cd $subdir make $local_target) \ || eval $failcom; \ done; \ if test $dot_seen = no; then \ make $target-am || exit 1; \ fi; test -z $fail make: Fatal error: Command failed for target `check-recursive' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Compiling protocol buffer source using aCC compiler on HP
Hello Folks, I would like to request help in here for compiling protocol buffer source using aCC compiler on HPUX Please provide some inputs if anybody has idea about problems . Vikram --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Sun Studio 11
Can somebody point out when this patch will be included in source?
I am trying to do compilation on Solaris 10 but right now I am getting
errors as mentioned in this post.
Vikram
On Jun 4, 1:42 pm, Kenton Varda ken...@google.com wrote:
Thanks for the patch!
It looks like you were using the examples as a test. Running make check
in the top directory will run a much better suite of tests -- do they pass?
Assuming it does work, can you re-send that patch as an attachment (it looks
like it has been mangled), or even send it to me via codereview.appspot.com?
Also, for me to submit it you'll need to sign the contributor license
agreement:
http://code.google.com/legal/individual-cla-v1.0.html-- if you own
copyright on this patchhttp://code.google.com/legal/corporate-cla-v1.0.html--
if your employer
does
On Wed, Jun 3, 2009 at 10:53 PM, bmcarnes_proto...@oddren.com wrote:
Probably not. LibCstd isn't complete enough for protobuf.
I was able to get protobuf 2.1.0 to work well under Sun Studio 11,
using libCstd, with a few patches. Works well enough to compile and
run the add_person_cpp/list_people_cpp examples.
I include the build instructions and patch set below Also included
are patches to the examples makefile to test it out.
Apply below patchset first against protobuf 2.1.0
$ CXX=CC CC=cc ./configure --disable-shared
$ make
$ cd examples
$ make cpp
$ ./add_person_cpp addressbook.test
(enter a test record)
$ ./list_people_cpp addressbook.test
(test record is displayed correctly)
$ ldd list_people_cpp (or ldd add_person_cpp )
libpthread.so.1 = /lib/libpthread.so.1
libCstd.so.1 = /usr/lib/libCstd.so.1
libCrun.so.1 = /usr/lib/libCrun.so.1
libm.so.2 = /lib/libm.so.2
libc.so.1 = /lib/libc.so.1
Index: src/google/protobuf/repeated_field.h
===
--- src/google/protobuf/repeated_field.h (revision 2)
+++ src/google/protobuf/repeated_field.h (working copy)
@@ -69,7 +69,7 @@
class LIBPROTOBUF_EXPORT GenericRepeatedField {
public:
inline GenericRepeatedField() {}
-#if defined(__DECCXX) defined(__osf__)
+#if defined(__SUNPRO_CC) || defined(__DECCXX) defined(__osf__)
// HP C++ on Tru64 has trouble when this is not defined inline.
virtual ~GenericRepeatedField() {}
#else
@@ -548,7 +548,7 @@
current_size_ = 0;
}
-#if defined(__DECCXX) defined(__osf__)
+#if defined(__SUNPRO_CC) || defined(__DECCXX) defined(__osf__)
// HP C++ on Tru64 has trouble when this is not defined inline.
template
inline void RepeatedPtrFieldstring::Clear() {
Index: src/google/protobuf/descriptor_database.cc
===
--- src/google/protobuf/descriptor_database.cc (revision 2)
+++ src/google/protobuf/descriptor_database.cc (working copy)
@@ -127,7 +127,13 @@
// Insert the new symbol using the iterator as a hint, the new
entry will
// appear immediately before the one the iterator is pointing at.
+
+ // Sun Studio 11 needs a little help here
+#if defined(__SUNPRO_CC)
+ by_symbol_.insert(iter, make_pairconst string,Value(name,
value));
+#else
by_symbol_.insert(iter, make_pair(name, value));
+#endif
return true;
}
Index: src/google/protobuf/compiler/command_line_interface.cc
===
--- src/google/protobuf/compiler/command_line_interface.cc (revision
2)
+++ src/google/protobuf/compiler/command_line_interface.cc (working
copy)
@@ -474,7 +474,7 @@
// If no --proto_path was given, use the current working directory.
if (proto_path_.empty()) {
- proto_path_.push_back(make_pair(, .));
+ proto_path_.push_back(make_pair(string(), string(.)));
}
// Check some errror cases.
Index: src/google/protobuf/repeated_field.cc
===
--- src/google/protobuf/repeated_field.cc (revision 2)
+++ src/google/protobuf/repeated_field.cc (working copy)
@@ -40,7 +40,7 @@
// HP C++ on Tru64 can't handle the stuff below being defined out-of-
line, so
// on that platform everything is defined in repeated_field.h. On
other
// platforms, we want these to be out-of-line to avoid code bloat.
-#if !defined(__DECCXX) || !defined(__osf__)
+#if !defined(__SUNPRO_CC) (!defined(__DECCXX) || !defined
(__osf__))
namespace internal {
--- Below changes the examples makefile to exercise protobuf under
solaris
Index: examples/Makefile
===
--- examples/Makefile (revision 2)
+++ examples/Makefile (working copy)
@@ -1,5 +1,13 @@
# See README.txt.
+# For the rest of the world
+#CXX = c++
+#PROTOC = protoc
+
+# Testing
