bizarre crash report on freebsd
Protobuf-c has a small bit in its test-suite that uses protobuf's c++ binding to generate packed versions of several messages that are compared with c binding packed data. I'm almost tempted to get rid of these fragile tests b/c they are such a build annoyance. But I'm going to try to keep them just to make certain testing easier (e.g. packed-repeated will be much easier to validate if i can test c v c++ directly). Anyways, the latest build issue is this mystifying bug report on freebsd (i have no idea if the OS is relevant really). http://code.google.com/p/protobuf-c/issues/detail?id=22 Since I don't have a freebsd box convenient i can't reproduce, which means i am stuck guessing from the bug report. The crash occurs in the static initializers (see backtrace in the bug report). My best guess is that static initializers in protobuf and the generated code need to be run in a certain order (ie generated code before libprotobuf, or maybe vice versa), and that isn't happening in this user's environment. Any ideas? --~--~-~--~~~---~--~~ 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
If the tests pass, it should be good to go. Please do submit patches. On Wed, Jun 24, 2009 at 2:09 PM, vikram wrote: > > 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 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
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 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 -~--~~~~--~~--~--~---
Re: Sun Studio 11
Rats. Ok, I'm seeing some problems now... let me get back to you. vikram wrote: > 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 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 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 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 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 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 wrote: > I haven't heard from the patch author since my previous mail. :/ > On Mon, Jun 22, 2009 at 4:06 PM, vikram 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 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, >>> 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 th
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
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 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 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 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 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 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 wrote: > >>> I haven't heard from the patch author since my previous mail. :/ > >>> On Mon, Jun 22, 2009 at 4:06 PM, vikram 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 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, > > 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. > >> > >> $ CXX=CC CC=cc ./configure --disable-sha
Re: Sun Studio 11
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 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 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 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 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 wrote: >>> I haven't heard from the patch author since my previous mail. :/ >>> On Mon, Jun 22, 2009 at 4:06 PM, vikram 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 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, > 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. >> >> $ 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/l
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 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 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 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 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 wrote: > > I haven't heard from the patch author since my previous mail. :/ > > On Mon, Jun 22, 2009 at 4:06 PM, vikram 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 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, > >>> 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. > > $ 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
Re: Sun Studio 11
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 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 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 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 wrote: > I haven't heard from the patch author since my previous mail. :/ > On Mon, Jun 22, 2009 at 4:06 PM, vikram 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 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, >>> 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. $ 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 Generi
Re: Sun Studio 11
I am using 2.1.0 only. On Jun 24, 12:26 pm, Kenton Varda 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 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 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 wrote: > > > > > I haven't heard from the patch author since my previous mail. :/ > > > > > On Mon, Jun 22, 2009 at 4:06 PM, vikram 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 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, > > 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. > > > > > > > > > > > > > > > $ 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) > > > > > > > @
Re: Sun Studio 11
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 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 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 wrote:
> >
> > > I haven't heard from the patch author since my previous mail. :/
> >
> > > On Mon, Jun 22, 2009 at 4:06 PM, vikram 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 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,
> 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.
> >
> > > > > >
> > > > > > $ 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
Re: Deserializing a message for which I don't have the .proto (in Java)
On Wed, Jun 24, 2009 at 11:55 AM, Toph wrote: > So if I know that a given byte blob is actually a packed array, how > can I decode it without having a precompiled proto definition? You would have to not only know that the blob is a packed array, but also the wire type of the elements in the array (varint, 32-bit, or 64-bit). Then you could manually decode the elements, using CodedInputStream. > The byte blob in question wouldn't be a complete message, so I can't > use UnknownFieldSet.parseFrom(), can I? > (unlike embedded messages) That is correct. > > > On Jun 25, 1:46 am, Kenton Varda wrote: > > On Wed, Jun 24, 2009 at 6:15 AM, Toph wrote: > > > > > Thanks for the reply Kenton. > > > > > Yes I discovered UnknownFieldSet, although it (and thus its toString > > > () ) isn't able to recurse down a tree of embedded messages stored in > > > length-delimited values (as far as I can see), so I've written a > > > recursive method to do just that (which has to try to parse such a > > > value in order to determine if it is an embedded message, or just a > > > bunch of bytes/text). > > > > Right, there is no way to distinguish between embedded messages and byte > > blobs without having the proto definition. > > > > I believe the C++ TextFormat code heuristically detects embedded messages > > when printing unknown fields, the same way you do. I don't think that's > > been ported to Java, though. > > > > > Is UnknownFieldSet able to handle packed repeated fields correctly and > > > parse them out of the length delimited value into one of the > > > UnknownFieldSet.Field.get*List() Lists, as opposed to just leaving > > > them packed in the value (as it does with embedded messages) ? I > > > assume so, but haven't tried it. > > > > No. Again, this requires knowing the proto definition. There's no way > to > > distinguish between packed arrays and byte blobs given only the encoded > > message. > > > > > I'm ok with the interface changing in a future version as long as it > > > supports extracting all of the data that it does today. > > > > Yes, it will contain all the same data, but it will no longer group the > data > > by field number. Instead it will just have an array of number/value > pairs > > in arbitrary order (with groups still represented as embedded > > UnknownFieldSets). > > > > > > > > > > > > > On Jun 24, 2:12 am, Kenton Varda wrote: > > > > You can use UnknownFieldSet, but be warned that the interface for > that > > > class > > > > is likely to change in a future version (because the current design > is > > > > somewhat inefficient). If you just want to print the contents, you > > > should > > > > be fine -- just parse into an UnknownFieldSet and then call its > > > toString() > > > > method. Those parts won't change. > > > > > > On Tue, Jun 23, 2009 at 7:46 AM, Toph wrote: > > > > > > > Hi folks, > > > > > > > I understand that protocol buffers messages are not fully self- > > > > > describing. > > > > > However, the message contains the field number, wire type, and > value, > > > > > right? > > > > > > > In Java, how can I take a byte[] (array of bytes) that represents a > > > > > message and deserialize it into a list of tuples that contain the > > > > > field number, wire type, and value? I really just want to print > out > > > > > these tuples, even if the value is binary. > > > > > > > Do any of the classes i the Java API provide a mechanism to do > this? > > > > > I know I could just take the documentation of the encoding and > write > > > > > code myself, but I am hoping that one of the API classes exists in > a > > > > > usable or near-usable form to do this for me. Will > CodedInputStream > > > > > do it? Can I use any of the parseFrom() or mergeFrom() methods? > > > > > > > Note that I do not have the corresponding .proto file in source > form, > > > > > compiled form, or available to transmit along with any messages > > > > > > > Thanks > > > --~--~-~--~~~---~--~~ 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: Deserializing a message for which I don't have the .proto (in Java)
> No. Again, this requires knowing the proto definition. There's no way to > distinguish between packed arrays and byte blobs given only the encoded > message. So if I know that a given byte blob is actually a packed array, how can I decode it without having a precompiled proto definition? The byte blob in question wouldn't be a complete message, so I can't use UnknownFieldSet.parseFrom(), can I? (unlike embedded messages) On Jun 25, 1:46 am, Kenton Varda wrote: > On Wed, Jun 24, 2009 at 6:15 AM, Toph wrote: > > > Thanks for the reply Kenton. > > > Yes I discovered UnknownFieldSet, although it (and thus its toString > > () ) isn't able to recurse down a tree of embedded messages stored in > > length-delimited values (as far as I can see), so I've written a > > recursive method to do just that (which has to try to parse such a > > value in order to determine if it is an embedded message, or just a > > bunch of bytes/text). > > Right, there is no way to distinguish between embedded messages and byte > blobs without having the proto definition. > > I believe the C++ TextFormat code heuristically detects embedded messages > when printing unknown fields, the same way you do. I don't think that's > been ported to Java, though. > > > Is UnknownFieldSet able to handle packed repeated fields correctly and > > parse them out of the length delimited value into one of the > > UnknownFieldSet.Field.get*List() Lists, as opposed to just leaving > > them packed in the value (as it does with embedded messages) ? I > > assume so, but haven't tried it. > > No. Again, this requires knowing the proto definition. There's no way to > distinguish between packed arrays and byte blobs given only the encoded > message. > > > I'm ok with the interface changing in a future version as long as it > > supports extracting all of the data that it does today. > > Yes, it will contain all the same data, but it will no longer group the data > by field number. Instead it will just have an array of number/value pairs > in arbitrary order (with groups still represented as embedded > UnknownFieldSets). > > > > > > > On Jun 24, 2:12 am, Kenton Varda wrote: > > > You can use UnknownFieldSet, but be warned that the interface for that > > class > > > is likely to change in a future version (because the current design is > > > somewhat inefficient). If you just want to print the contents, you > > should > > > be fine -- just parse into an UnknownFieldSet and then call its > > toString() > > > method. Those parts won't change. > > > > On Tue, Jun 23, 2009 at 7:46 AM, Toph wrote: > > > > > Hi folks, > > > > > I understand that protocol buffers messages are not fully self- > > > > describing. > > > > However, the message contains the field number, wire type, and value, > > > > right? > > > > > In Java, how can I take a byte[] (array of bytes) that represents a > > > > message and deserialize it into a list of tuples that contain the > > > > field number, wire type, and value? I really just want to print out > > > > these tuples, even if the value is binary. > > > > > Do any of the classes i the Java API provide a mechanism to do this? > > > > I know I could just take the documentation of the encoding and write > > > > code myself, but I am hoping that one of the API classes exists in a > > > > usable or near-usable form to do this for me. Will CodedInputStream > > > > do it? Can I use any of the parseFrom() or mergeFrom() methods? > > > > > Note that I do not have the corresponding .proto file in source form, > > > > compiled form, or available to transmit along with any messages > > > > > Thanks --~--~-~--~~~---~--~~ 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 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 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 wrote:
>
> > I haven't heard from the patch author since my previous mail. :/
>
> > On Mon, Jun 22, 2009 at 4:06 PM, vikram 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 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, 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.
>
> > > > >
> > > > > $ 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(__
Re: New enum values
It will be treated like an unknown field. In C++ or Java, the value goes into the UnknownFieldSet, so if you then serialize the message, it will still be there. In Python it will just be discarded. On Wed, Jun 24, 2009 at 2:56 AM, Stuart Johnson wrote: > > If a new enum value had been added to a enum type, and it's being > deserialised by an application that is not yet aware of the new enum > value, what should happen? > > Should the enum value be null, or should the deserialisation abort? > > > > > --~--~-~--~~~---~--~~ 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: Deserializing a message for which I don't have the .proto (in Java)
On Wed, Jun 24, 2009 at 6:15 AM, Toph wrote: > > Thanks for the reply Kenton. > > Yes I discovered UnknownFieldSet, although it (and thus its toString > () ) isn't able to recurse down a tree of embedded messages stored in > length-delimited values (as far as I can see), so I've written a > recursive method to do just that (which has to try to parse such a > value in order to determine if it is an embedded message, or just a > bunch of bytes/text). Right, there is no way to distinguish between embedded messages and byte blobs without having the proto definition. I believe the C++ TextFormat code heuristically detects embedded messages when printing unknown fields, the same way you do. I don't think that's been ported to Java, though. > Is UnknownFieldSet able to handle packed repeated fields correctly and > parse them out of the length delimited value into one of the > UnknownFieldSet.Field.get*List() Lists, as opposed to just leaving > them packed in the value (as it does with embedded messages) ? I > assume so, but haven't tried it. No. Again, this requires knowing the proto definition. There's no way to distinguish between packed arrays and byte blobs given only the encoded message. > I'm ok with the interface changing in a future version as long as it > supports extracting all of the data that it does today. Yes, it will contain all the same data, but it will no longer group the data by field number. Instead it will just have an array of number/value pairs in arbitrary order (with groups still represented as embedded UnknownFieldSets). > > > On Jun 24, 2:12 am, Kenton Varda wrote: > > You can use UnknownFieldSet, but be warned that the interface for that > class > > is likely to change in a future version (because the current design is > > somewhat inefficient). If you just want to print the contents, you > should > > be fine -- just parse into an UnknownFieldSet and then call its > toString() > > method. Those parts won't change. > > > > > > > > On Tue, Jun 23, 2009 at 7:46 AM, Toph wrote: > > > > > Hi folks, > > > > > I understand that protocol buffers messages are not fully self- > > > describing. > > > However, the message contains the field number, wire type, and value, > > > right? > > > > > In Java, how can I take a byte[] (array of bytes) that represents a > > > message and deserialize it into a list of tuples that contain the > > > field number, wire type, and value? I really just want to print out > > > these tuples, even if the value is binary. > > > > > Do any of the classes i the Java API provide a mechanism to do this? > > > I know I could just take the documentation of the encoding and write > > > code myself, but I am hoping that one of the API classes exists in a > > > usable or near-usable form to do this for me. Will CodedInputStream > > > do it? Can I use any of the parseFrom() or mergeFrom() methods? > > > > > Note that I do not have the corresponding .proto file in source form, > > > compiled form, or available to transmit along with any messages > > > > > Thanks > > > --~--~-~--~~~---~--~~ 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: encoding of embedded messages and repeated elements
The end-tag approach is more efficient than your idea -- it's faster (no
need to count elements at all) and it takes no more space (no need to write
a count, which makes up for the extra space taken by the end tag).
But in any case, the encoding is not something we can change at this point,
since protocol buffers is nothing without backwards-compatibility.
And yes, some existing parsers do, in fact, take advantage of the ability to
skip over messages without parsing them, and there are many features that
people are considering implementing (like lazy parsing) which would need
this.
It actually turns out that pre-computing the size of the embedded message
does not take very long compared to actually writing it.
On Wed, Jun 24, 2009 at 12:57 AM, etorri wrote:
>
>
> Does some existing parser actually implement that skipping feature?
>
> There would not be any need for a end-tag. Let's assume that there
> would be two different tags
>
> 2 - Length_Delimited, which could contain a packed list of bytes
> (string, memory block) or other types where the parser needs to know
> what is packed inside (no tags)
> 6 - Group or Element_Delimited - which would be like Length_Delimited
> but have the number of elements that follow that belong to this field
>
> So for an example message where the first field is a group
>
> (1,6),3 - field numbered 1 of the message, type 6 = Group and 3
> elements that follow belong to this group
> (1,2),5,"Hello" -field number 1 of the embedded message would be a
> string
> (3,1),120 - field nr 3 of the embedded message, varint of value 120
> (4,1),0 - field nr 4 of the embedded message, varint of value 0
> (2,2),5,"World" - field nr 2 of the message
>
> this would be the encoding of the following TheMessage
>
> message Embedded {
> required string greeting = 1;
> optional int32 useless = 2;
> required int32 good = 3;
> required int32 evil = 4;
> }
>
> message TheMessage {
> required Embedded e = 1;
> required string target = 2;
> }
>
> So in this case there would not be need for an end tag. When
> constructing the message it should be relatively easy to count the
> number of embedded elements instead of knowing how much space they
> occupy. This would enable streaming/serializing the elements
> recursively out one by one.
>
>
>
> On Jun 23, 9:07 pm, Kenton Varda wrote:
> > The advantage of writing the length is that a parser can skip the entire
> > sub-message easily without having to parse its contents. Otherwise, we
> > would probably use the "group" encoding for sub-messages, where a special
> > end tag marks the end of the message.
> >
>
> >
>
--~--~-~--~~~---~--~~
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: Deserializing a message for which I don't have the .proto (in Java)
Thanks for the reply Kenton. Yes I discovered UnknownFieldSet, although it (and thus its toString () ) isn't able to recurse down a tree of embedded messages stored in length-delimited values (as far as I can see), so I've written a recursive method to do just that (which has to try to parse such a value in order to determine if it is an embedded message, or just a bunch of bytes/text). Is UnknownFieldSet able to handle packed repeated fields correctly and parse them out of the length delimited value into one of the UnknownFieldSet.Field.get*List() Lists, as opposed to just leaving them packed in the value (as it does with embedded messages) ? I assume so, but haven't tried it. I'm ok with the interface changing in a future version as long as it supports extracting all of the data that it does today. On Jun 24, 2:12 am, Kenton Varda wrote: > You can use UnknownFieldSet, but be warned that the interface for that class > is likely to change in a future version (because the current design is > somewhat inefficient). If you just want to print the contents, you should > be fine -- just parse into an UnknownFieldSet and then call its toString() > method. Those parts won't change. > > > > On Tue, Jun 23, 2009 at 7:46 AM, Toph wrote: > > > Hi folks, > > > I understand that protocol buffers messages are not fully self- > > describing. > > However, the message contains the field number, wire type, and value, > > right? > > > In Java, how can I take a byte[] (array of bytes) that represents a > > message and deserialize it into a list of tuples that contain the > > field number, wire type, and value? I really just want to print out > > these tuples, even if the value is binary. > > > Do any of the classes i the Java API provide a mechanism to do this? > > I know I could just take the documentation of the encoding and write > > code myself, but I am hoping that one of the API classes exists in a > > usable or near-usable form to do this for me. Will CodedInputStream > > do it? Can I use any of the parseFrom() or mergeFrom() methods? > > > Note that I do not have the corresponding .proto file in source form, > > compiled form, or available to transmit along with any messages > > > Thanks --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
New enum values
If a new enum value had been added to a enum type, and it's being deserialised by an application that is not yet aware of the new enum value, what should happen? Should the enum value be null, or should the deserialisation abort? --~--~-~--~~~---~--~~ 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: encoding of embedded messages and repeated elements
Does some existing parser actually implement that skipping feature?
There would not be any need for a end-tag. Let's assume that there
would be two different tags
2 - Length_Delimited, which could contain a packed list of bytes
(string, memory block) or other types where the parser needs to know
what is packed inside (no tags)
6 - Group or Element_Delimited - which would be like Length_Delimited
but have the number of elements that follow that belong to this field
So for an example message where the first field is a group
(1,6),3 - field numbered 1 of the message, type 6 = Group and 3
elements that follow belong to this group
(1,2),5,"Hello" -field number 1 of the embedded message would be a
string
(3,1),120 - field nr 3 of the embedded message, varint of value 120
(4,1),0 - field nr 4 of the embedded message, varint of value 0
(2,2),5,"World" - field nr 2 of the message
this would be the encoding of the following TheMessage
message Embedded {
required string greeting = 1;
optional int32 useless = 2;
required int32 good = 3;
required int32 evil = 4;
}
message TheMessage {
required Embedded e = 1;
required string target = 2;
}
So in this case there would not be need for an end tag. When
constructing the message it should be relatively easy to count the
number of embedded elements instead of knowing how much space they
occupy. This would enable streaming/serializing the elements
recursively out one by one.
On Jun 23, 9:07 pm, Kenton Varda wrote:
> The advantage of writing the length is that a parser can skip the entire
> sub-message easily without having to parse its contents. Otherwise, we
> would probably use the "group" encoding for sub-messages, where a special
> end tag marks the end of the message.
>
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
