Hello there,
I'm usually a linux developer, but I occasionally have to develop some
Windows applications.
I have a Gtk + Cairo + ProtocolBuffers that was ported to windows some
months ago without any problem.
Now I have a new one, with similar setup but a few more dependencies
(CGAL, RSVG and ot
The stack trace you provided looks like it is from v2.0.3. The
initialization code changed drastically in 2.1.0 -- the method
DescriptorPool::InternalBuildGeneratedFile no longer exists, for example.
Can you provide a stack trace using 2.1.0?
On Fri, Jun 26, 2009 at 8:07 AM, rodrigob wrote:
>
>
On Thu, Jun 25, 2009 at 6:59 PM, vikram wrote:
>
> Hello guys,
>
> I am actually attempting to compile protocol buffer source on
> AIX 5.3 and xlC 3.55 .
> It seems that I am able to compile it correctly but when it tried to
> use created protoc compiler it fails.
> So following it the snap
Yes I am using v 2.1.0
I provided compiler option "-qrtti=all " . So compilation went
smoothly but last step where
protoc is uses proto files seems like running in infinite loop. I am
currently looking at it
Vikram
On Jun 26, 12:32 pm, Kenton Varda wrote:
> On Thu, Jun 25, 2009 at 6:59 PM, vi
bash-3.00$ gdb src/.libs/lt-protoc
GNU gdb 5.1.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
Ther
Can you do a build with debug info to get line numbers?
On Fri, Jun 26, 2009 at 1:29 PM, vikram wrote:
>
>
> bash-3.00$ gdb src/.libs/lt-protoc
> GNU gdb 5.1.1
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are
> welco
@Kentan
I built with debug info and got following stack trace .
location of compiler is at /usr/vacpp/bin if its not by default.
#0 0xd1afa248 in
__lt__3stdHcQ2_3std11char_traitsXTc_Q2_3std9allocatorXTc__RCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__RCQ2_3std12basi
This isn't telling me much. Can you interrupt and continue a few times to
get a few different stack traces, in order to find out what the common part
of the trace is? This should allow us to determine which loop is failing to
terminate.
On Fri, Jun 26, 2009 at 2:49 PM, vikram wrote:
>
> @Kenta
