Example not compatible with protoc 2.4.0rc1 about protobuf-for-node HOT 6 CLOSED

Interesting. I get a "version not compatible, please regenerate" warning from 
compiling the .pb.cc . Will see what I can do, I'd like to keep this compatible 
with 2.3.0 until 2.4.0 is released for good.

If someone understands waf well enough it would be useful to generate the 
example code during building.

Thanks for the report
Matthias

I'm getting crashes w/ 2.4.0rc1 on Snow Leopard while loading the extension. 
Will investigate further:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x00007fff83e690aa in std::string::_Rep::_M_grab ()
(gdb) where
#0  0x00007fff83e690aa in std::string::_Rep::_M_grab ()
#1  0x00007fff83e69171 in std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >::basic_string ()
#2  0x0000000125273256 in pair [inlined] () at stl_pair.h:85
#3  0x0000000125273256 in pair [inlined] () at 
/usr/include/c++/4.2.1/bits/stl_pair.h:112
#4  0x0000000125273256 in 
google::protobuf::InsertIfNotPresent<std::map<std::string, std::pair<void 
const*, int>, std::less<std::string>, std::allocator<std::pair<std::string 
const, std::pair<void const*, int> > > >, std::string, std::pair<void const*, 
int> > (collection=0x10070e638, key=<value temporarily unavailable, due to 
optimizations>, value=@0x7fff5fbfe7b0) at stl_pair.h:85
#5  0x0000000125273338 in 
google::protobuf::SimpleDescriptorDatabase::DescriptorIndex<std::pair<void 
const*, int> >::AddFile (this=0x10070e638, file=@0x7fff5fbfe880, value={first = 
0x12545fb58, second = 3681}) at google/protobuf/descriptor_database.cc:56
#6  0x00000001253e68d0 in google::protobuf::EncodedDescriptorDatabase::Add 
(this=0x10070e630, encoded_file_descriptor=0x12545fb58, size=3681) at 
google/protobuf/descriptor_database.cc:312
#7  0x00000001253e47dd in 
google::protobuf::DescriptorPool::InternalAddGeneratedFile 
(encoded_file_descriptor=0x12545fb58, size=3681) at 
google/protobuf/descriptor.cc:860
#8  0x00000001253e5d4e in 
google::protobuf::protobuf_AddDesc_google_2fprotobuf_2fdescriptor_2eproto () at 
google/protobuf/descriptor.pb.cc:599
#9  0x00000001253e665d in std::string::_Rep::_M_refdata () at 
/usr/include/c++/4.2.1/bits/basic_string.h:644
#10 0x00000001253e665d in basic_string [inlined] () at 
google/protobuf/descriptor.pb.cc:2067
#11 0x00000001253e665d in basic_string [inlined] () at 
/usr/include/c++/4.2.1/bits/basic_string.h:2067
#12 0x00000001253e665d in __static_initialization_and_destruction_0 
(__initialize_p=<value temporarily unavailable, due to optimizations>, 
__priority=<value temporarily unavailable, due to optimizations>) at 
google/protobuf/descriptor.pb.cc:856
#13 0x00007fff5fc0d500 in 
__dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE 
()
#14 0x00007fff5fc0bcec in 
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#15 0x00007fff5fc0bc9d in 
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#16 0x00007fff5fc0bc9d in 
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#17 0x00007fff5fc0bda6 in 
__dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
#18 0x00007fff5fc08fbb in __dyld_dlopen ()
#19 0x00007fff851bc2c0 in dlopen ()
#20 0x00000001000076ca in node::DLOpen (args=@0x7fff5fbfeeb0) at 
../src/node.cc:1263
#21 0x000000010007c885 in v8::internal::Builtin_HandleApiCall ()

I used the branch node3 of your project to compile your lib and I compiled node 
0.3 and protobuf 2.4 without any issues.

I also run the example: node example/feeds.js 
Message after roundtrip: {
  "title": "Title"
}
Number of entries: 2
Proto: 11.7 us / object
JSON: 2.75 us / object

Nevermind, it somehow pulled in a 2.3.0 dylib instead. So I can confirm that 
2.4.0rc1 works and I've pushed the generic_cc_services option change. I won't 
update the checked-in code before 2.4.0 gets released since it doesn't compile 
against 2.3.0. I've added a comment to the build instructions.

Or would you suggest I make "node3" the unstable branch with all bleeding-edge 
dependencies (node 3 isn't stable either)?

Thanks,
Matthias

It's not a bad idea to have an experimental branch dedicated to the coming 
version (lib, tools, ...) this way you will be able to merge it easily and your 
lib will be always up to date.

Upgraded default branch to require node 0.4, protobuf 2.4.0a.
Use branch node2 for node2/protobuf 2.3.0.