[protobuf] Sun Studio 11 on Solaris 8, i386: two unit tests are failing

[Maciej Bliziński]

I got protobuf to build on Solaris 8.  All tests are passing on sparc
(both 32 and 64-bit), two tests are failing on i386.  (amd64 build is
yet to come)

[  FAILED  ] CommandLineInterfaceTest.OutputDirectoryIsFileError
[  FAILED  ] DiskSourceTreeTest.MapDirectory


[ RUN  ] DiskSourceTreeTest.MapDirectory
google/protobuf/compiler/importer_unittest.cc:376: Failure
Value of: input == NULL
  Actual: false
Expected: true

[ RUN  ] CommandLineInterfaceTest.OutputDirectoryIsFileError
google/protobuf/compiler/command_line_interface_unittest.cc:341:
Failure
Value of: expected_substring
  Actual: "foo.proto/: Not a directory"
Expected: a substring of error_text_
Which is: "/var/tmp/aaafCa4JF/proto2_cli_test_temp/foo.proto/
foo.proto.MockCodeGenerator.test_generator: Not a directory"
[  FAILED  ] CommandLineInterfaceTest.OutputDirectoryIsFileError (14
ms)

Maciej

-- 
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: Sun Studio 11

[Kenton Varda]

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
-~--~~~~--~~--~--~---

Re: Sun Studio 11

[vikram]

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

[Monty Taylor]

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

Re: Sun Studio 11

[vikram]

@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

[vikram]

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 

Re: Sun Studio 11

[Monty Taylor]

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
>>>>>>&

Re: Sun Studio 11

[vikram]

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
> >>>>>

Re: Sun Studio 11

[Monty Taylor]

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

Re: Sun Studio 11

[vikram]

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 pa

Re: Sun Studio 11

[Kenton Varda]

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)
> &g

Re: Sun Studio 11

[vikram]

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
> > > > > ===

Re: Sun Studio 11

[vikram]

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--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,  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(__osf__)
> > > >  // HP C++ on Tru64 has trouble when this is not defined inline.
> > > >  template <>
> > > >  inline void RepeatedPtrField::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_pair(name,
> > > > value));
> > > > +#else
> > > >   by_symbol_.insert

Re: Sun Studio 11

[Kenton Varda]

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-- 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,  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(__osf__)
> > >  // HP C++ on Tru64 has trouble when this is not defined inline.
> > >  template <>
> > >  inline void RepeatedPtrField::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_pair(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_

Re: Sun Studio 11

[vikram]

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-- 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,  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(__osf__)
> >  // HP C++ on Tru64 has trouble when this is not defined inline.
> >  template <>
> >  inline void RepeatedPtrField::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_pair(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 @@
> >  // H

Re: Sun Studio 11

[Kenton Varda]

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 patch
http://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(__osf__)
>  // HP C++ on Tru64 has trouble when this is not defined inline.
>  template <>
>  inline void RepeatedPtrField::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_pair(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   (wo

Re: Sun Studio 11

[bmcarnes_protobuf]

> 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(__osf__)
 // HP C++ on Tru64 has trouble when this is not defined inline.
 template <>
 inline void RepeatedPtrField::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_pair(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 For Solaris (pre-install)
+CXX = CC -I../src -L../src/.libs
+PROTOC = ../src/protoc
+
 .PHONY: all cpp java python clean

 all: cpp java python
@@ -18,14 +26,14 @@
rmdir com 2>/dev/null || true

 protoc_middleman: addressbook.proto
-   protoc --cpp_out=. --java_out=. --python_out=. addressbook.proto
+   $(PROTOC) --cpp_out=. --java_out=. --python_out=. addressbook.proto
@touch protoc_middleman

 add_person_cpp: add_person.cc protoc_middleman
-   c++ add_person.cc addressbook.pb.cc -lprotobuf -lpthread -o
add_person_cpp
+   $(CXX) add_person.cc addressbook.pb.cc -lprotobuf -lpthread -o
add_person_cpp

 list_people_cpp: list_people.cc protoc_middleman
-   c++ list_people.cc addressbook.pb.cc -lprotobuf -lpthread -o
list_people_cpp
+   $(CXX) list_people.cc addressbook.pb.cc -lprotobuf -lpthread -o
list_people_cpp

 javac_middleman: AddPerson.java ListPeople.java protoc_middleman
javac AddPerson.java ListPeople.java com/example/tutorial/
AddressBookProtos.j

Sun Studio 11

[ajoy]

Hi

I compiled 2.10 in Sun studio 11, with the -library=stlport4 option,
but I have to link protobuf against other programs which are not
compiled with this option (and whose source code i don't have) , and i
believe they're incompatible because of this.

Is there any hope for me? :)

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: Compiling protocol buffers 2.0.3 with sun studio 11

[Monty Taylor]

Kenton Varda wrote:
> PS. Did you see the patch on issue 105 for ptrdiff and offsets_ ?
> 
> 
> Yeargh, I wish I could tell the code site to e-mail me whenever someone
> submits an issue, because I always forget to go look.

Yeah. I completely agree... It doesn't seem to email on updates either.
I just uploaded the int-cast patch, and it does, in fact, seem to work.
(There is nothing special in the patch - just the int-cast in the macro,
in case you don't feel like actually applying the patch.)

Monty

--~--~-~--~~~---~--~~
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 protocol buffers 2.0.3 with sun studio 11

[Kenton Varda]

Submitted as rev 151.

On Wed, May 27, 2009 at 5:44 PM, Monty Taylor  wrote:

> PS. Did you see the patch on issue 105 for ptrdiff and offsets_ ?
>

Yeargh, I wish I could tell the code site to e-mail me whenever someone
submits an issue, because I always forget to go look.


>
> === modified file 'm4/acx_check_suncc.m4'
> --- m4/acx_check_suncc.m4   2009-05-28 09:33:56 +
> +++ m4/acx_check_suncc.m4   2009-05-28 09:34:20 +
> @@ -12,7 +12,8 @@
>
>  AC_DEFUN([ACX_CHECK_SUNCC],[
>
> -  AC_CHECK_DECL([__SUNPRO_C], [SUNCC="yes"], [SUNCC="no"])
> +  AC_LANG_PUSH([C++])
> +  AC_CHECK_DECL([__SUNPRO_CC], [SUNCC="yes"], [SUNCC="no"])
>
>   AS_IF([test "$SUNCC" = "yes"],[
> isainfo_k=`isainfo -k`
> @@ -30,4 +31,5 @@
> CFLAGS="-g -xO4 -xlibmil -xdepend -Xa -mt -xstrconst ${IS_64}
> ${MEMALIGN_FLAGS} $CFLAGS"
> CXXFLAGS="-g -xO4 -xlibmil -mt ${IS_64} ${MEMALIGN_FLAGS} -xlang=c99
> -compat=5 -library=stlport4 -template=no%extdef $CXXFLAGS"
>   ])
> +  AC_LANG_POP()
>  ])
>
>
>

--~--~-~--~~~---~--~~
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 protocol buffers 2.0.3 with sun studio 11

[Monty Taylor]

Kenton Varda wrote:
> Thanks for the patch, Monty.
> 
> Unfortunately it looks like it has been mangled somewhere in flight.
>  Can you send it as an attachment instead?

No problem! Here you go.

Monty


PS. Did you see the patch on issue 105 for ptrdiff and offsets_ ?

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

=== modified file 'm4/acx_check_suncc.m4'
--- m4/acx_check_suncc.m4   2009-05-28 09:33:56 +
+++ m4/acx_check_suncc.m4   2009-05-28 09:34:20 +
@@ -12,7 +12,8 @@
 
 AC_DEFUN([ACX_CHECK_SUNCC],[
 
-  AC_CHECK_DECL([__SUNPRO_C], [SUNCC="yes"], [SUNCC="no"])
+  AC_LANG_PUSH([C++])
+  AC_CHECK_DECL([__SUNPRO_CC], [SUNCC="yes"], [SUNCC="no"])
 
   AS_IF([test "$SUNCC" = "yes"],[
 isainfo_k=`isainfo -k`
@@ -30,4 +31,5 @@
 CFLAGS="-g -xO4 -xlibmil -xdepend -Xa -mt -xstrconst ${IS_64} 
${MEMALIGN_FLAGS} $CFLAGS"
 CXXFLAGS="-g -xO4 -xlibmil -mt ${IS_64} ${MEMALIGN_FLAGS} -xlang=c99 
-compat=5 -library=stlport4 -template=no%extdef $CXXFLAGS"
   ])
+  AC_LANG_POP()
 ])

Re: Compiling protocol buffers 2.0.3 with sun studio 11

[Kenton Varda]

Thanks for the patch, Monty.
Unfortunately it looks like it has been mangled somewhere in flight.  Can
you send it as an attachment instead?

On Thu, May 21, 2009 at 11:01 AM, Monty Taylor  wrote:

> Kenton Varda wrote:
> > On Wed, May 20, 2009 at 12:58 PM, Monty Taylor  > > wrote:
> >
> > Works fine then, as I'm using it pretty consistently with Sun Studio
> -
> > guess it's just the pedanticness.
> >
> >
> > Note that the whole "once" thing is new in 2.1.0 -- you've tested that
> > one, right?
>
> Ok. I reproduced (sorry - turns out I hadn't done 2.1.0 on my solaris
> boxes yet - only on my linux boxes) and fixed.
>
> The Sun autoconf check was assuming language and was checking for
> __SUNPRO_C, but at some point an AC_LANG_PUSH(C++) had happened and
> hadn't been popped. Solution: add an explicit PUSH and POP in the test.
> :) The real key for the build failure is making sure -template=no%extdef
> is in the CXXFLAGS
>
> BTW, I'll put together a different patch that does the CXXFLAGS setting
> stuff more cleanly. You are right - we should eventually be setting
> AM_CXXFLAGS here.
>
> diff -Nru protobuf-2.1.0/m4/acx_check_suncc.m4
> protobuf-2.1.0-mt/m4/acx_check_suncc.m4
> --- protobuf-2.1.0/m4/acx_check_suncc.m42009-05-13
> 13:36:16.0 -0700
> +++ protobuf-2.1.0-mt/m4/acx_check_suncc.m4 2009-05-21
> 19:57:41.917760080 -0700
> @@ -12,7 +12,9 @@
>
>  AC_DEFUN([ACX_CHECK_SUNCC],[
>
> -  AC_CHECK_DECL([__SUNPRO_C], [SUNCC="yes"], [SUNCC="no"])
> +  AC_LANG_PUSH([C++])
> +
> +  AC_CHECK_DECL([__SUNPRO_CC], [SUNCC="yes"], [SUNCC="no"])
>
>   AS_IF([test "$SUNCC" = "yes"],[
> isainfo_k=`isainfo -k`
> @@ -30,4 +32,5 @@
> CFLAGS="-g -xO4 -xlibmil -xdepend -Xa -mt -xstrconst ${IS_64}
> ${MEMALIGN_FLAGS} $CFLAGS"
> CXXFLAGS="-g -xO4 -xlibmil -mt ${IS_64} ${MEMALIGN_FLAGS}
> -xlang=c99 -compat=5 -library=stlport4 -template=no%extdef $CXXFLAGS"
>   ])
> +  AC_LANG_POP()
>  ])
>

--~--~-~--~~~---~--~~
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 protocol buffers 2.0.3 with sun studio 11

[Monty Taylor]

Kenton Varda wrote:
> On Wed, May 20, 2009 at 12:58 PM, Monty Taylor  > wrote:
> 
> Works fine then, as I'm using it pretty consistently with Sun Studio -
> guess it's just the pedanticness.
> 
> 
> Note that the whole "once" thing is new in 2.1.0 -- you've tested that
> one, right?

Ok. I reproduced (sorry - turns out I hadn't done 2.1.0 on my solaris
boxes yet - only on my linux boxes) and fixed.

The Sun autoconf check was assuming language and was checking for
__SUNPRO_C, but at some point an AC_LANG_PUSH(C++) had happened and
hadn't been popped. Solution: add an explicit PUSH and POP in the test.
:) The real key for the build failure is making sure -template=no%extdef
is in the CXXFLAGS

BTW, I'll put together a different patch that does the CXXFLAGS setting
stuff more cleanly. You are right - we should eventually be setting
AM_CXXFLAGS here.

diff -Nru protobuf-2.1.0/m4/acx_check_suncc.m4
protobuf-2.1.0-mt/m4/acx_check_suncc.m4
--- protobuf-2.1.0/m4/acx_check_suncc.m42009-05-13
13:36:16.0 -0700
+++ protobuf-2.1.0-mt/m4/acx_check_suncc.m4 2009-05-21
19:57:41.917760080 -0700
@@ -12,7 +12,9 @@

 AC_DEFUN([ACX_CHECK_SUNCC],[

-  AC_CHECK_DECL([__SUNPRO_C], [SUNCC="yes"], [SUNCC="no"])
+  AC_LANG_PUSH([C++])
+
+  AC_CHECK_DECL([__SUNPRO_CC], [SUNCC="yes"], [SUNCC="no"])

   AS_IF([test "$SUNCC" = "yes"],[
 isainfo_k=`isainfo -k`
@@ -30,4 +32,5 @@
 CFLAGS="-g -xO4 -xlibmil -xdepend -Xa -mt -xstrconst ${IS_64}
${MEMALIGN_FLAGS} $CFLAGS"
 CXXFLAGS="-g -xO4 -xlibmil -mt ${IS_64} ${MEMALIGN_FLAGS}
-xlang=c99 -compat=5 -library=stlport4 -template=no%extdef $CXXFLAGS"
   ])
+  AC_LANG_POP()
 ])

--~--~-~--~~~---~--~~
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 protocol buffers 2.0.3 with sun studio 11

[Kenton Varda]

On Wed, May 20, 2009 at 12:58 PM, Monty Taylor  wrote:

> Works fine then, as I'm using it pretty consistently with Sun Studio -
> guess it's just the pedanticness.


Note that the whole "once" thing is new in 2.1.0 -- you've tested that one,
right?

--~--~-~--~~~---~--~~
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 protocol buffers 2.0.3 with sun studio 11

[Monty Taylor]

Kenton Varda wrote:
> 
> 
> On Wed, May 20, 2009 at 10:44 AM, Monty Taylor  > wrote:
> 
> Kenton Varda wrote:
> >
> >
> > On Wed, May 20, 2009 at 12:35 AM,  
> >  >> wrote:
> >
> > "./google/protobuf/stubs/once.h", line 114: Warning (Anachronism):
> > Formal argument 2 of type extern "C" void(*)() in call to
> pthread_once
> > (_once*, extern "C" void(*)()) is being passed void(*)().
> >
> >
> > This warning seems to be saying that pointers to functions with extern
> > "C" are not compatible with pointers to normal functions.  If this is
> > the case then that's a serious problem and I don't know what to do
> about
> > it.  But I think it's more likely that this is just bogus.
> 
> AIUI, it stems from the fact that the Sun Studio C and C++ compilers are
> separate... but I'm not 100% sure about that. In general, if you are
> passing a pointer to a function that was compiled in C++ land, Sun
> Studio is going to complain if you don't declare that function to have C
> linkage. I had to do that for all of my callback functions in
> Drizzle. :)
> 
> Now - as for it _actually_ being a problem, I don't know - I can ask
> someone though if you think it's important to learn.
> 
> 
> If it doesn't work then libprotobuf is completely broken on sun studio,
> because we rely on being able to pass non-extern-C functions to
> pthread_once.

Works fine then, as I'm using it pretty consistently with Sun Studio -
guess it's just the pedanticness.

Monty

--~--~-~--~~~---~--~~
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 protocol buffers 2.0.3 with sun studio 11

[Kenton Varda]

On Wed, May 20, 2009 at 10:44 AM, Monty Taylor  wrote:

> Kenton Varda wrote:
> >
> >
> > On Wed, May 20, 2009 at 12:35 AM,  > > wrote:
> >
> > "./google/protobuf/stubs/once.h", line 114: Warning (Anachronism):
> > Formal argument 2 of type extern "C" void(*)() in call to
> pthread_once
> > (_once*, extern "C" void(*)()) is being passed void(*)().
> >
> >
> > This warning seems to be saying that pointers to functions with extern
> > "C" are not compatible with pointers to normal functions.  If this is
> > the case then that's a serious problem and I don't know what to do about
> > it.  But I think it's more likely that this is just bogus.
>
> AIUI, it stems from the fact that the Sun Studio C and C++ compilers are
> separate... but I'm not 100% sure about that. In general, if you are
> passing a pointer to a function that was compiled in C++ land, Sun
> Studio is going to complain if you don't declare that function to have C
> linkage. I had to do that for all of my callback functions in Drizzle. :)
>
> Now - as for it _actually_ being a problem, I don't know - I can ask
> someone though if you think it's important to learn.


If it doesn't work then libprotobuf is completely broken on sun studio,
because we rely on being able to pass non-extern-C functions to
pthread_once.

--~--~-~--~~~---~--~~
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 protocol buffers 2.0.3 with sun studio 11

[Monty Taylor]

Kenton Varda wrote:
> 
> 
> On Wed, May 20, 2009 at 12:35 AM,  > wrote:
> 
> "./google/protobuf/stubs/once.h", line 114: Warning (Anachronism):
> Formal argument 2 of type extern "C" void(*)() in call to pthread_once
> (_once*, extern "C" void(*)()) is being passed void(*)().
> 
> 
> This warning seems to be saying that pointers to functions with extern
> "C" are not compatible with pointers to normal functions.  If this is
> the case then that's a serious problem and I don't know what to do about
> it.  But I think it's more likely that this is just bogus.

AIUI, it stems from the fact that the Sun Studio C and C++ compilers are
separate... but I'm not 100% sure about that. In general, if you are
passing a pointer to a function that was compiled in C++ land, Sun
Studio is going to complain if you don't declare that function to have C
linkage. I had to do that for all of my callback functions in Drizzle. :)

Now - as for it _actually_ being a problem, I don't know - I can ask
someone though if you think it's important to learn.

Monty

--~--~-~--~~~---~--~~
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 protocol buffers 2.0.3 with sun studio 11

[Kenton Varda]

On Wed, May 20, 2009 at 12:35 AM,  wrote:

> "./google/protobuf/stubs/once.h", line 114: Warning (Anachronism):
> Formal argument 2 of type extern "C" void(*)() in call to pthread_once
> (_once*, extern "C" void(*)()) is being passed void(*)().


This warning seems to be saying that pointers to functions with extern "C"
are not compatible with pointers to normal functions.  If this is the case
then that's a serious problem and I don't know what to do about it.  But I
think it's more likely that this is just bogus.


> "./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/wire_format.h", line 177: Warning: Identifier
> expected instead of "}".


These are just complaining that an enum had a trailing comma, like:
  enum {A, B, C, };

This is valid C++ so I'd say the warning is bogus.


> "./google/protobuf/repeated_field.cc", line 52: Error:
> google::protobuf::RepeatedPtrField::Clear() already had a
> body defined.


This error is incorrect.  This looks like a case of poor template support.
 There was a body defined for a general RepeatedPtrField::Clear(), but
repeated_field.h also explicitly specializes for string on line 563 without
defining a method body -- the body is in repeated_field.cc.

Perhaps the hack used to work around problems with HP C++/Tru64 should also
apply to Sun Studio?

If you can make it work, send me a patch.

--~--~-~--~~~---~--~~
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 protocol buffers 2.0.3 with sun studio 11

[Monty Taylor]

cosmin.cremare...@gmail.com wrote:
> I'm using libtool v2.2.6
> 
> To make sure that protobuf always links to stlport I added CXXFLAGS="-
> library=stlport4" to the configure command.

Well... you shouldn't need to do that, we're forcing that on in
configure anyway. :)

> At the end I get the same linking errors.
> Is the below warning from ld meaningful?
> ld: warning: file /src/work/mw/protobuf-2.0.3-sunstudio11/src/.libs/
> libprotobuf.so: linked to ./.libs/libprotobuf.so: attempted multiple
> inclusion of file

Don't think so - I'm going to go recompile and see if I can reproduce.

> Regards,
> 
> Cosmin
> 
> On May 19, 10:14 pm, Monty Taylor  wrote:
>> cosmin.cremare...@gmail.com wrote:
>>> Hi
>>> I'm running into some issues when compiling (more exactly linking)
>>> protobuf 2.0.3.
>>> Thanks in advance for any help.
>>> Cosmin
>>> CXX=/nettools/sunstudio/sunstudio11/SUNWspro/bin/CC CC=/nettools/
>>> sunstudio/sunstudio11/SUNWspro/bin/cc ./configure --prefix=/src/work/
>>> mw/protobuf-2.0.3-sunstudio11-build LDFLAGS=-L$PWD/src/solaris
>>> bash$ uname -a
>>> SunOS pegasus 5.10 Generic_118855-33 i86pc i386 i86pc
>>> pegasus ccremarenco /src/work/mw/protobuf-2.0.3-sunstudio11/
>>> bash$ CC -V
>>> CC: Sun C++ 5.8 Patch 121018-11 2007/05/02
>> Well... it looks fine on the surface - but there may have been a problem
>> further back in your build histoy. Are there any references to -Cstd in
>> there? If so, you need to install libtool 2.2 and then re-run autogen.sh
>> (older libtools do bad things on solaris) But I don't remember having
>> had to do that last time I built.
>>
>>> /bin/bash ../libtool --tag=CXX --mode=link /nettools/sunstudio/
>>> sunstudio11/SUNWspro/bin/CC -D_REENTRANT  -g -xO4 -xlibmil -mt -
>>> D_FORTEC_ -xlang=c99 -compat=5 -library=stlport4 -template=no%extdef -
>>> D_REENTRANT -L/src/work/mw/protobuf-2.0.3-sunstudio11/src/solaris -o
>>> protoc  main.o -lpthread libprotobuf.la libprotoc.la
>>> libtool: link: /nettools/sunstudio/sunstudio11/SUNWspro/bin/CC -
>>> D_REENTRANT -g -xO4 -xlibmil -mt -D_FORTEC_ -xlang=c99 -compat=5 -
>>> template=no%extdef -D_REENTRANT -o .libs/protoc main.o  -L/src/work/mw/
>>> protobuf-2.0.3-sunstudio11/src/solaris ./.libs/libprotobuf.so ./.libs/
>>> libprotoc.so /src/work/mw/protobuf-2.0.3-sunstudio11/src/.libs/
>>> libprotobuf.so -library=stlport4 -lpthread -mt -R/src/work/mw/
>>> protobuf-2.0.3-sunstudio11-build/lib
>>> ld: warning: file /src/work/mw/protobuf-2.0.3-sunstudio11/src/.libs/
>>> libprotobuf.so: linked to ./.libs/libprotobuf.so: attempted multiple
>>> inclusion of file
>>> Undefined   first referenced
>>>  symbol in file
>>> std::pair>> google::protobuf::Descriptor*,std::_Nonconst_traits>> google::protobuf::Descriptor*> >,bool>std::_Rb_tree>> google::protobuf::Descriptor*,const
>>> google::protobuf::Descriptor*,std::_Identity>> google::protobuf::Descriptor*>,std::less>> google::protobuf::Descriptor*>,std::allocator>> google::protobuf::Descriptor*> >::insert_unique(const
>>> google::protobuf::Descriptor*const&) ./.libs/libprotobuf.so
>>> unsigned std::hashtable>> google::protobuf::FileDescriptor*>,const
>>> char*,google::protobuf::hash>> char*>,std::_Select1st>> google::protobuf::FileDescriptor*>
 ,google::protobuf::__unnamed_sWhGbsSnEKGIw::CStringEqual,std::allocator>>>  ::pair>> char*const,const google::protobuf::FileDescriptor*> > >::erase(const
>>> char*const&) ./.libs/libprotobuf.so
>>> void std::_Rb_tree>> std::string,google::protobuf::compiler::CommandLineInterface::GeneratorInfo 
>>> >,std::_Select1st>> std::string,google::protobuf::compiler::CommandLineInterface::GeneratorInfo 
>>> >
 ,std::less,std::allocator>> std::string,google::protobuf::compiler::CommandLineInterface::GeneratorInfo 
>>> >
> ::_M_erase(std::_Rb_tree_node>> std::string,google::protobuf::compiler::CommandLineInterface::GeneratorInfo 
>>> >
 *) ./.libs/libprotoc.so
>>> std::pair>> google::protobuf::FileDescriptor*,std::_Nonconst_traits>> google::protobuf::FileDescriptor*> >,bool>std::_Rb_tree>> google::protobuf::FileDescriptor*,const
>>> google::protobuf::FileDescriptor*,std::_Identity>> google::protobuf::FileDescriptor*>,std::less>> google::protobuf::FileDescriptor*>,std::allocator>> google::protobuf::FileDescriptor*> >::insert_unique(const
>>> google::protobuf::FileDescriptor*const&) ./.libs/libprotoc.so
>>> void std::_Rb_tree>> int,google::protobuf::UnknownField*>,std::_Select1st>> int,google::protobuf::UnknownField*>
 ,std::less,std::allocator>> int,google::protobuf::UnknownField*> > >::_M_erase
>>> (std::_Rb_tree_node>> int,google::protobuf::UnknownField*> >*) ./.libs/libprotobuf.so
>>> std::pair>> google::protobuf::Descriptor*const,const
>>> google::protobuf::Message*>,std::_Nonconst_traits>> google::protobuf::Descriptor*const,const google::protobuf::Message*>
 ,const google::protobuf::Descriptor*,google::protobuf::hash>> google::protobuf::Descriptor*>,std::_Select1st>> google::protobuf::D

Re: Compiling protocol buffers 2.0.3 with sun studio 11

[cosmin . cremarenco]

I'm using libtool v2.2.6

To make sure that protobuf always links to stlport I added CXXFLAGS="-
library=stlport4" to the configure command.
At the end I get the same linking errors.
Is the below warning from ld meaningful?
ld: warning: file /src/work/mw/protobuf-2.0.3-sunstudio11/src/.libs/
libprotobuf.so: linked to ./.libs/libprotobuf.so: attempted multiple
inclusion of file

Regards,

Cosmin

On May 19, 10:14 pm, Monty Taylor  wrote:
> cosmin.cremare...@gmail.com wrote:
> > Hi
>
> > I'm running into some issues when compiling (more exactly linking)
> > protobuf 2.0.3.
>
> > Thanks in advance for any help.
> > Cosmin
>
> > CXX=/nettools/sunstudio/sunstudio11/SUNWspro/bin/CC CC=/nettools/
> > sunstudio/sunstudio11/SUNWspro/bin/cc ./configure --prefix=/src/work/
> > mw/protobuf-2.0.3-sunstudio11-build LDFLAGS=-L$PWD/src/solaris
>
> > bash$ uname -a
> > SunOS pegasus 5.10 Generic_118855-33 i86pc i386 i86pc
> > pegasus ccremarenco /src/work/mw/protobuf-2.0.3-sunstudio11/
> > bash$ CC -V
> > CC: Sun C++ 5.8 Patch 121018-11 2007/05/02
>
> Well... it looks fine on the surface - but there may have been a problem
> further back in your build histoy. Are there any references to -Cstd in
> there? If so, you need to install libtool 2.2 and then re-run autogen.sh
> (older libtools do bad things on solaris) But I don't remember having
> had to do that last time I built.
>
> > /bin/bash ../libtool --tag=CXX --mode=link /nettools/sunstudio/
> > sunstudio11/SUNWspro/bin/CC -D_REENTRANT  -g -xO4 -xlibmil -mt -
> > D_FORTEC_ -xlang=c99 -compat=5 -library=stlport4 -template=no%extdef -
> > D_REENTRANT -L/src/work/mw/protobuf-2.0.3-sunstudio11/src/solaris -o
> > protoc  main.o -lpthread libprotobuf.la libprotoc.la
> > libtool: link: /nettools/sunstudio/sunstudio11/SUNWspro/bin/CC -
> > D_REENTRANT -g -xO4 -xlibmil -mt -D_FORTEC_ -xlang=c99 -compat=5 -
> > template=no%extdef -D_REENTRANT -o .libs/protoc main.o  -L/src/work/mw/
> > protobuf-2.0.3-sunstudio11/src/solaris ./.libs/libprotobuf.so ./.libs/
> > libprotoc.so /src/work/mw/protobuf-2.0.3-sunstudio11/src/.libs/
> > libprotobuf.so -library=stlport4 -lpthread -mt -R/src/work/mw/
> > protobuf-2.0.3-sunstudio11-build/lib
> > ld: warning: file /src/work/mw/protobuf-2.0.3-sunstudio11/src/.libs/
> > libprotobuf.so: linked to ./.libs/libprotobuf.so: attempted multiple
> > inclusion of file
> > Undefined                       first referenced
> >  symbol                             in file
> > std::pair > google::protobuf::Descriptor*,std::_Nonconst_traits > google::protobuf::Descriptor*> >,bool>std::_Rb_tree > google::protobuf::Descriptor*,const
> > google::protobuf::Descriptor*,std::_Identity > google::protobuf::Descriptor*>,std::less > google::protobuf::Descriptor*>,std::allocator > google::protobuf::Descriptor*> >::insert_unique(const
> > google::protobuf::Descriptor*const&) ./.libs/libprotobuf.so
> > unsigned std::hashtable > google::protobuf::FileDescriptor*>,const
> > char*,google::protobuf::hash > char*>,std::_Select1st > google::protobuf::FileDescriptor*>
> >> ,google::protobuf::__unnamed_sWhGbsSnEKGIw::CStringEqual,std::allocator >>  ::pair > char*const,const google::protobuf::FileDescriptor*> > >::erase(const
> > char*const&) ./.libs/libprotobuf.so
> > void std::_Rb_tree > std::string,google::protobuf::compiler::CommandLineInterface::GeneratorInfo 
> > >,std::_Select1st > std::string,google::protobuf::compiler::CommandLineInterface::GeneratorInfo 
> > >
> >> ,std::less,std::allocator > std::string,google::protobuf::compiler::CommandLineInterface::GeneratorInfo 
> > >
> >>> ::_M_erase(std::_Rb_tree_node > std::string,google::protobuf::compiler::CommandLineInterface::GeneratorInfo 
> > >
> >> *) ./.libs/libprotoc.so
> > std::pair > google::protobuf::FileDescriptor*,std::_Nonconst_traits > google::protobuf::FileDescriptor*> >,bool>std::_Rb_tree > google::protobuf::FileDescriptor*,const
> > google::protobuf::FileDescriptor*,std::_Identity > google::protobuf::FileDescriptor*>,std::less > google::protobuf::FileDescriptor*>,std::allocator > google::protobuf::FileDescriptor*> >::insert_unique(const
> > google::protobuf::FileDescriptor*const&) ./.libs/libprotoc.so
> > void std::_Rb_tree > int,google::protobuf::UnknownField*>,std::_Select1st > int,google::protobuf::UnknownField*>
> >> ,std::less,std::allocator > int,google::protobuf::UnknownField*> > >::_M_erase
> > (std::_Rb_tree_node > int,google::protobuf::UnknownField*> >*) ./.libs/libprotobuf.so
> > std::pair > google::protobuf::Descriptor*const,const
> > google::protobuf::Message*>,std::_Nonconst_traits > google::protobuf::Descriptor*const,const google::protobuf::Message*>
> >> ,const google::protobuf::Descriptor*,google::protobuf::hash > google::protobuf::Descriptor*>,std::_Select1st > google::protobuf::Descriptor*const,const google::protobuf::Message*>
> >> ,std::equal_to > google::protobuf::Descriptor*>,std::allocator > google::protobuf::Descriptor*const,const google::protobuf::Message*> >
> >> ,bool>std::hashtable > 

Re: Compiling protocol buffers 2.0.3 with sun studio 11

[cosmin . cremarenco]

I have access to sun studio 12 so I tried to compile protobuf 2.1.0
with this version of the compiler.
This is the error I get:

make  all-recursive
Making all in .
Making all in src
source='google/protobuf/descriptor.pb.cc' object='descriptor.pb.lo'
libtool=yes \
DEPDIR=.deps depmode=none /bin/bash ../depcomp \
/bin/bash ../libtool --tag=CXX   --mode=compile /nettools/sunstudio/
sunstudio12/SUNWspro/bin/CC -DHAVE_CONFIG_H -I. -I..-D_REENTRANT  -
g -DNDEBUG -c -o descriptor.pb.lo `test -f 'google/protobuf   /
descriptor.pb.cc' || echo './'`google/protobuf/descriptor.pb.cc
libtool: compile:  /nettools/sunstudio/sunstudio12/SUNWspro/bin/CC -
DHAVE_CONFIG_H -I. -I.. -D_REENTRANT -g -DNDEBUG -c google/protobuf/
descriptor.pb.cc  -KPIC -DPIC -o .libs/descriptor.pb.o
"./google/protobuf/stubs/once.h", line 114: Warning (Anachronism):
Formal argument 2 of type extern "C" void(*)() in call to pthread_once
(_once*, extern "C" void(*)()) is being passed void(*)().
"./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/wire_format.h", line 177: Warning: Identifier
expected instead of "}".
"./google/protobuf/repeated_field.cc", line 52: Error:
google::protobuf::RepeatedPtrField::Clear() already had a
body defined.
1 Error(s) and 5 Warning(s) detected.


On May 19, 10:15 pm, Kenton Varda  wrote:
> Can you try 2.1.0?  Some patches were submitted specifically for improving
> sun studio support.  Check the README, too, for some sun/solaris-specific
> tips.
> Let me know if that doesn't work.
>
> On Tue, May 19, 2009 at 2:11 AM,  wrote:
>
> > Hi
>
> > I'm running into some issues when compiling (more exactly linking)
> > protobuf 2.0.3.
>
> > Thanks in advance for any help.
> > Cosmin
>
> > CXX=/nettools/sunstudio/sunstudio11/SUNWspro/bin/CC CC=/nettools/
> > sunstudio/sunstudio11/SUNWspro/bin/cc ./configure --prefix=/src/work/
> > mw/protobuf-2.0.3-sunstudio11-build LDFLAGS=-L$PWD/src/solaris
>
> > bash$ uname -a
> > SunOS pegasus 5.10 Generic_118855-33 i86pc i386 i86pc
> > pegasus ccremarenco /src/work/mw/protobuf-2.0.3-sunstudio11/
> > bash$ CC -V
> > CC: Sun C++ 5.8 Patch 121018-11 2007/05/02
>
> > /bin/bash ../libtool --tag=CXX --mode=link /nettools/sunstudio/
> > sunstudio11/SUNWspro/bin/CC -D_REENTRANT  -g -xO4 -xlibmil -mt -
> > D_FORTEC_ -xlang=c99 -compat=5 -library=stlport4 -template=no%extdef -
> > D_REENTRANT -L/src/work/mw/protobuf-2.0.3-sunstudio11/src/solaris -o
> > protoc  main.o -lpthread libprotobuf.la libprotoc.la
> > libtool: link: /nettools/sunstudio/sunstudio11/SUNWspro/bin/CC -
> > D_REENTRANT -g -xO4 -xlibmil -mt -D_FORTEC_ -xlang=c99 -compat=5 -
> > template=no%extdef -D_REENTRANT -o .libs/protoc main.o  -L/src/work/mw/
> > protobuf-2.0.3-sunstudio11/src/solaris ./.libs/libprotobuf.so ./.libs/
> > libprotoc.so /src/work/mw/protobuf-2.0.3-sunstudio11/src/.libs/
> > libprotobuf.so -library=stlport4 -lpthread -mt -R/src/work/mw/
> > protobuf-2.0.3-sunstudio11-build/lib
> > ld: warning: file /src/work/mw/protobuf-2.0.3-sunstudio11/src/.libs/
> > libprotobuf.so: linked to ./.libs/libprotobuf.so: attempted multiple
> > inclusion of file
> > Undefined                       first referenced
> >  symbol                             in file
> > std::pair > google::protobuf::Descriptor*,std::_Nonconst_traits > google::protobuf::Descriptor*> >,bool>std::_Rb_tree > google::protobuf::Descriptor*,const
> > google::protobuf::Descriptor*,std::_Identity > google::protobuf::Descriptor*>,std::less > google::protobuf::Descriptor*>,std::allocator > google::protobuf::Descriptor*> >::insert_unique(const
> > google::protobuf::Descriptor*const&) ./.libs/libprotobuf.so
> > unsigned std::hashtable > google::protobuf::FileDescriptor*>,const
> > char*,google::protobuf::hash > char*>,std::_Select1st > google::protobuf::FileDescriptor*>
>
> > >,google::protobuf::__unnamed_sWhGbsSnEKGIw::CStringEqual,std::allocator > >d::pair > char*const,const google::protobuf::FileDescriptor*> > >::erase(const
> > char*const&) ./.libs/libprotobuf.so
> > void std::_Rb_tree
> > std::string,google::protobuf::compiler::CommandLineInterface::GeneratorInfo 
> > >,std::_Select1st
> > std::string,google::protobuf::compiler::CommandLineInterface::GeneratorInfo 
> > >
> > >,std::less,std::allocator
> > std::string,google::protobuf::compiler::CommandLineInterface::GeneratorInfo 
> > >
> > > >::_M_erase(std::_Rb_tree_node
> > std::string,google::protobuf::compiler::CommandLineInterface::GeneratorInfo 
> > >
> > >*) ./.libs/libprotoc.so
> > std::pair > google::protobuf::FileDescriptor*,std::_Nonconst_traits > google::protobuf::FileDescriptor*> >,bool>std::_Rb_tree > google::protobuf::FileDescriptor*,const
> > google::protobuf::FileDescriptor*,std::_Identity > google::protobuf::FileDescriptor*>,std::less > google::protobuf::

Re: Compiling protocol buffers 2.0.3 with sun studio 11

[cosmin . cremarenco]

Thanks for your quick replies.

I tried to compile protobuf 2.1.0 with sun studio 11, this is what I
get:

make  all-recursive
Making all in .
Making all in src
source='google/protobuf/descriptor_database.cc'
object='descriptor_database.lo' libtool=yes \
DEPDIR=.deps depmode=none /bin/bash ../depcomp \
/bin/bash ../libtool --tag=CXX   --mode=compile /nettools/sunstudio/
sunstudio11/SUNWspro/bin/CC -DHAVE_CONFIG_H -I. -I..-D_REENTRANT  -
g -DNDEBUG -c -o descriptor_database.lo `test -f 'google/protobuf/
descriptor_database.cc' || echo
'./'`google/protobuf/descriptor_database.cc
libtool: compile:  /nettools/sunstudio/sunstudio11/SUNWspro/bin/CC -
DHAVE_CONFIG_H -I. -I.. -D_REENTRANT -g -DNDEBUG -c google/protobuf/
descriptor_database.cc  -KPIC -DPIC -o .libs/descriptor_database.o
"./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/descriptor_database.cc", line 130: Error: Could not
find a match for std::map::insert
(__rwstd::__rb_tree, __rwstd::__select1st,
std::string>, std::less, std::allocator>>::iterator, std::pair) needed in
google::protobuf::SimpleDescriptorDatabase::DescriptorIndex::AddSymbol(const s
td::string &, const google::protobuf::FileDescriptorProto*).
"google/protobuf/descriptor_database.cc", line 67: Where: While
instantiating
"google::protobuf::SimpleDescriptorDatabase::DescriptorIndex::AddSymbol(const std::string
&, const google::pr
otobuf::FileDescriptorProto*)".
"google/protobuf/descriptor_database.cc", line 67: Where:
Instantiated from
google::protobuf::SimpleDescriptorDatabase::DescriptorIndex::AddFile(const
google::protobuf::FileDescriptorProt
o&, const google::protobuf::FileDescriptorProto*).
"google/protobuf/descriptor_database.cc", line 263: Where:
Instantiated from non-template code.
1 Error(s) and 3 Warning(s) detected.


On May 19, 10:15 pm, Kenton Varda  wrote:
> Can you try 2.1.0?  Some patches were submitted specifically for improving
> sun studio support.  Check the README, too, for some sun/solaris-specific
> tips.
> Let me know if that doesn't work.
>
> On Tue, May 19, 2009 at 2:11 AM,  wrote:
>
> > Hi
>
> > I'm running into some issues when compiling (more exactly linking)
> > protobuf 2.0.3.
>
> > Thanks in advance for any help.
> > Cosmin
>
> > CXX=/nettools/sunstudio/sunstudio11/SUNWspro/bin/CC CC=/nettools/
> > sunstudio/sunstudio11/SUNWspro/bin/cc ./configure --prefix=/src/work/
> > mw/protobuf-2.0.3-sunstudio11-build LDFLAGS=-L$PWD/src/solaris
>
> > bash$ uname -a
> > SunOS pegasus 5.10 Generic_118855-33 i86pc i386 i86pc
> > pegasus ccremarenco /src/work/mw/protobuf-2.0.3-sunstudio11/
> > bash$ CC -V
> > CC: Sun C++ 5.8 Patch 121018-11 2007/05/02
>
> > /bin/bash ../libtool --tag=CXX --mode=link /nettools/sunstudio/
> > sunstudio11/SUNWspro/bin/CC -D_REENTRANT  -g -xO4 -xlibmil -mt -
> > D_FORTEC_ -xlang=c99 -compat=5 -library=stlport4 -template=no%extdef -
> > D_REENTRANT -L/src/work/mw/protobuf-2.0.3-sunstudio11/src/solaris -o
> > protoc  main.o -lpthread libprotobuf.la libprotoc.la
> > libtool: link: /nettools/sunstudio/sunstudio11/SUNWspro/bin/CC -
> > D_REENTRANT -g -xO4 -xlibmil -mt -D_FORTEC_ -xlang=c99 -compat=5 -
> > template=no%extdef -D_REENTRANT -o .libs/protoc main.o  -L/src/work/mw/
> > protobuf-2.0.3-sunstudio11/src/solaris ./.libs/libprotobuf.so ./.libs/
> > libprotoc.so /src/work/mw/protobuf-2.0.3-sunstudio11/src/.libs/
> > libprotobuf.so -library=stlport4 -lpthread -mt -R/src/work/mw/
> > protobuf-2.0.3-sunstudio11-build/lib
> > ld: warning: file /src/work/mw/protobuf-2.0.3-sunstudio11/src/.libs/
> > libprotobuf.so: linked to ./.libs/libprotobuf.so: attempted multiple
> > inclusion of file
> > Undefined                       first referenced
> >  symbol                             in file
> > std::pair > google::protobuf::Descriptor*,std::_Nonconst_traits > google::protobuf::Descriptor*> >,bool>std::_Rb_tree > google::protobuf::Descriptor*,const
> > google::protobuf::Descriptor*,std::_Identity > google::protobuf::Descriptor*>,std::less > google::protobuf::Descriptor*>,std::allocator > google::protobuf::Descriptor*> >::insert_unique(const
> > google::protobuf::Descriptor*const&) ./.libs/libprotobuf.so
> > unsigned std::hashtable > google::protobuf::FileDescriptor*>,const
> > char*,google::protobuf::hash > char*>,std::_Select1st

Re: Compiling protocol buffers 2.0.3 with sun studio 11

[Monty Taylor]

cosmin.cremare...@gmail.com wrote:
> Hi
> 
> I'm running into some issues when compiling (more exactly linking)
> protobuf 2.0.3.
> 
> Thanks in advance for any help.
> Cosmin
> 
> CXX=/nettools/sunstudio/sunstudio11/SUNWspro/bin/CC CC=/nettools/
> sunstudio/sunstudio11/SUNWspro/bin/cc ./configure --prefix=/src/work/
> mw/protobuf-2.0.3-sunstudio11-build LDFLAGS=-L$PWD/src/solaris
> 
> bash$ uname -a
> SunOS pegasus 5.10 Generic_118855-33 i86pc i386 i86pc
> pegasus ccremarenco /src/work/mw/protobuf-2.0.3-sunstudio11/
> bash$ CC -V
> CC: Sun C++ 5.8 Patch 121018-11 2007/05/02

Well... it looks fine on the surface - but there may have been a problem
further back in your build histoy. Are there any references to -Cstd in
there? If so, you need to install libtool 2.2 and then re-run autogen.sh
(older libtools do bad things on solaris) But I don't remember having
had to do that last time I built.

> /bin/bash ../libtool --tag=CXX --mode=link /nettools/sunstudio/
> sunstudio11/SUNWspro/bin/CC -D_REENTRANT  -g -xO4 -xlibmil -mt -
> D_FORTEC_ -xlang=c99 -compat=5 -library=stlport4 -template=no%extdef -
> D_REENTRANT -L/src/work/mw/protobuf-2.0.3-sunstudio11/src/solaris -o
> protoc  main.o -lpthread libprotobuf.la libprotoc.la
> libtool: link: /nettools/sunstudio/sunstudio11/SUNWspro/bin/CC -
> D_REENTRANT -g -xO4 -xlibmil -mt -D_FORTEC_ -xlang=c99 -compat=5 -
> template=no%extdef -D_REENTRANT -o .libs/protoc main.o  -L/src/work/mw/
> protobuf-2.0.3-sunstudio11/src/solaris ./.libs/libprotobuf.so ./.libs/
> libprotoc.so /src/work/mw/protobuf-2.0.3-sunstudio11/src/.libs/
> libprotobuf.so -library=stlport4 -lpthread -mt -R/src/work/mw/
> protobuf-2.0.3-sunstudio11-build/lib
> ld: warning: file /src/work/mw/protobuf-2.0.3-sunstudio11/src/.libs/
> libprotobuf.so: linked to ./.libs/libprotobuf.so: attempted multiple
> inclusion of file
> Undefined   first referenced
>  symbol in file
> std::pair google::protobuf::Descriptor*,std::_Nonconst_traits google::protobuf::Descriptor*> >,bool>std::_Rb_tree google::protobuf::Descriptor*,const
> google::protobuf::Descriptor*,std::_Identity google::protobuf::Descriptor*>,std::less google::protobuf::Descriptor*>,std::allocator google::protobuf::Descriptor*> >::insert_unique(const
> google::protobuf::Descriptor*const&) ./.libs/libprotobuf.so
> unsigned std::hashtable google::protobuf::FileDescriptor*>,const
> char*,google::protobuf::hash char*>,std::_Select1st google::protobuf::FileDescriptor*>
>> ,google::protobuf::__unnamed_sWhGbsSnEKGIw::CStringEqual,std::allocator char*const,const google::protobuf::FileDescriptor*> > >::erase(const
> char*const&) ./.libs/libprotobuf.so
> void std::_Rb_tree std::string,google::protobuf::compiler::CommandLineInterface::GeneratorInfo>,std::_Select1st std::string,google::protobuf::compiler::CommandLineInterface::GeneratorInfo>
>> ,std::less,std::allocator std::string,google::protobuf::compiler::CommandLineInterface::GeneratorInfo>
>>> ::_M_erase(std::_Rb_tree_node std::string,google::protobuf::compiler::CommandLineInterface::GeneratorInfo>
>> *) ./.libs/libprotoc.so
> std::pair google::protobuf::FileDescriptor*,std::_Nonconst_traits google::protobuf::FileDescriptor*> >,bool>std::_Rb_tree google::protobuf::FileDescriptor*,const
> google::protobuf::FileDescriptor*,std::_Identity google::protobuf::FileDescriptor*>,std::less google::protobuf::FileDescriptor*>,std::allocator google::protobuf::FileDescriptor*> >::insert_unique(const
> google::protobuf::FileDescriptor*const&) ./.libs/libprotoc.so
> void std::_Rb_tree int,google::protobuf::UnknownField*>,std::_Select1st int,google::protobuf::UnknownField*>
>> ,std::less,std::allocator int,google::protobuf::UnknownField*> > >::_M_erase
> (std::_Rb_tree_node int,google::protobuf::UnknownField*> >*) ./.libs/libprotobuf.so
> std::pair google::protobuf::Descriptor*const,const
> google::protobuf::Message*>,std::_Nonconst_traits google::protobuf::Descriptor*const,const google::protobuf::Message*>
>> ,const google::protobuf::Descriptor*,google::protobuf::hash google::protobuf::Descriptor*>,std::_Select1st google::protobuf::Descriptor*const,const google::protobuf::Message*>
>> ,std::equal_to google::protobuf::Descriptor*>,std::allocator google::protobuf::Descriptor*const,const google::protobuf::Message*> >
>> ,bool>std::hashtable google::protobuf::Descriptor*const,const
> google::protobuf::Message*>,const
> google::protobuf::Descriptor*,google::protobuf::hash google::protobuf::Descriptor*>,std::_Select1st google::protobuf::Descriptor*const,const google::protobuf::Message*>
>> ,std::equal_to google::protobuf::Descriptor*>,std::allocator google::protobuf::Descriptor*const,const google::protobuf::Message*> >
>> ::insert_unique_noresize(const std::pair google::protobuf::Descriptor*const,const
> google::protobuf::Message*>&) ./.libs/libprotobuf.so
> std::pair google::protobuf::FileDescriptor*>,std::_Nonconst_traits char*const,const google::protobuf::FileDescriptor*> >,const

Compiling protocol buffers 2.0.3 with sun studio 11

[cosmin . cremarenco]

Hi

I'm running into some issues when compiling (more exactly linking)
protobuf 2.0.3.

Thanks in advance for any help.
Cosmin

CXX=/nettools/sunstudio/sunstudio11/SUNWspro/bin/CC CC=/nettools/
sunstudio/sunstudio11/SUNWspro/bin/cc ./configure --prefix=/src/work/
mw/protobuf-2.0.3-sunstudio11-build LDFLAGS=-L$PWD/src/solaris

bash$ uname -a
SunOS pegasus 5.10 Generic_118855-33 i86pc i386 i86pc
pegasus ccremarenco /src/work/mw/protobuf-2.0.3-sunstudio11/
bash$ CC -V
CC: Sun C++ 5.8 Patch 121018-11 2007/05/02

/bin/bash ../libtool --tag=CXX --mode=link /nettools/sunstudio/
sunstudio11/SUNWspro/bin/CC -D_REENTRANT  -g -xO4 -xlibmil -mt -
D_FORTEC_ -xlang=c99 -compat=5 -library=stlport4 -template=no%extdef -
D_REENTRANT -L/src/work/mw/protobuf-2.0.3-sunstudio11/src/solaris -o
protoc  main.o -lpthread libprotobuf.la libprotoc.la
libtool: link: /nettools/sunstudio/sunstudio11/SUNWspro/bin/CC -
D_REENTRANT -g -xO4 -xlibmil -mt -D_FORTEC_ -xlang=c99 -compat=5 -
template=no%extdef -D_REENTRANT -o .libs/protoc main.o  -L/src/work/mw/
protobuf-2.0.3-sunstudio11/src/solaris ./.libs/libprotobuf.so ./.libs/
libprotoc.so /src/work/mw/protobuf-2.0.3-sunstudio11/src/.libs/
libprotobuf.so -library=stlport4 -lpthread -mt -R/src/work/mw/
protobuf-2.0.3-sunstudio11-build/lib
ld: warning: file /src/work/mw/protobuf-2.0.3-sunstudio11/src/.libs/
libprotobuf.so: linked to ./.libs/libprotobuf.so: attempted multiple
inclusion of file
Undefined   first referenced
 symbol in file
std::pair >,bool>std::_Rb_tree,std::less,std::allocator >::insert_unique(const
google::protobuf::Descriptor*const&) ./.libs/libprotobuf.so
unsigned std::hashtable,const
char*,google::protobuf::hash,std::_Select1st
>,google::protobuf::__unnamed_sWhGbsSnEKGIw::CStringEqual,std::allocator > >::erase(const
char*const&) ./.libs/libprotobuf.so
void std::_Rb_tree,std::_Select1st
>,std::less,std::allocator
> >::_M_erase(std::_Rb_tree_node
>*) ./.libs/libprotoc.so
std::pair >,bool>std::_Rb_tree,std::less,std::allocator >::insert_unique(const
google::protobuf::FileDescriptor*const&) ./.libs/libprotoc.so
void std::_Rb_tree,std::_Select1st
>,std::less,std::allocator > >::_M_erase
(std::_Rb_tree_node >*) ./.libs/libprotobuf.so
std::pair,std::_Nonconst_traits
>,const google::protobuf::Descriptor*,google::protobuf::hash,std::_Select1st
>,std::equal_to,std::allocator >
>,bool>std::hashtable,const
google::protobuf::Descriptor*,google::protobuf::hash,std::_Select1st
>,std::equal_to,std::allocator >
>::insert_unique_noresize(const std::pair&) ./.libs/libprotobuf.so
std::pair,std::_Nonconst_traits >,const
char*,google::protobuf::hash,std::_Select1st
>,google::protobuf::__unnamed_sWhGbsSnEKGIw::CStringEqual,std::allocator >
>,bool>std::hashtable,const
char*,google::protobuf::hash,std::_Select1st
>,google::protobuf::__unnamed_sWhGbsSnEKGIw::CStringEqual,std::allocator >
>::insert_unique_noresize(const std::pair&) ./.libs/libprotobuf.so
void std::_Rb_tree,std::_Select1st
>,std::less,std::allocator > >::_M_erase
(std::_Rb_tree_node
>*) ./.libs/libprotobuf.so
void std::_Rb_tree,std::less,std::allocator >::_M_erase
(std::_Rb_tree_node*) ./.libs/
libprotoc.so
void std::_Rb_tree,std::less,std::allocator >::_M_erase(std::_Rb_tree_node*) ./.libs/libprotobuf.so
unsigned std::hashtable,const
google::protobuf::FieldDescriptor*>,std::pair,google::protobuf::__unnamed_sWhGbsSnEKGIw::PointerIntegerPairHash >,std::_Select1st,const
google::protobuf::FieldDescriptor*> >,std::equal_to >,std::allocator,const
google::protobuf::FieldDescriptor*> > >::_M_next_size(unsigned)
const ./.libs/libprotobuf.so
void std::_Rb_tree,std::pair,const
google::protobuf::FileDescriptorProto*>,std::_Select1st,const
google::protobuf::FileDescriptorProto*>
>,std::less
>,std::allocator,const
google::protobuf::FileDescriptorProto*> > >::_M_erase
(std::_Rb_tree_node,const
google::protobuf::FileDescriptorProto*> >*) ./.libs/libprotobuf.so
void std::hashtable,google::protobuf::__unnamed_sWhGbsSnEKGIw::Symbol>,std::pair,google::protobuf::__unnamed_sWhGbsSnEKGIw::PointerStringPairHash,std::_Select1st,google::protobuf::__unnamed_sWhGbsSnEKGIw::Symbol>
>,google::protobuf::__unnamed_sWhGbsSnEKGIw::PointerStringPairEqual,std::allocator,google::protobuf::__unnamed_sWhGbsSnEKGIw::Symbol> > >::clear
() ./.libs/libprotobuf.so
std::_Rb_tree_iterator,std::_Nonconst_traits > >std::_Rb_tree,std::_Select1st
>,std::less,std::allocator > >::insert_unique
(std::_Rb_tree_iterator,std::_Nonconst_traits > >,const std::pair&) ./.libs/libprotobuf.so
void std::sort
(__type_0,__type_0,__type_1) ./.libs/libprotobuf.so
void std::sort
(__type_0,__type_0,__type_1) ./.libs/libprotoc.so
void std::_Rb_tree,std::_Select1st
>,std::less,std::allocator > >::_M_erase
(std::_Rb_tree_node >*) ./.libs/
libprotobuf.so
std::_Rb_tree_iterator,std::_Nonconst_traits >
>std::_Rb_tree,std::_Select1st
>,std::less,std::allocator > >::insert_unique
(std::_Rb_tree_iterator,std::_Nonconst_traits > >,const std::pair&) ./.libs/libpr