Status: New
Owner: ken...@google.com
Labels: Type-Defect Priority-Medium
New issue 241 by palotai@gmail.com: Java Tutorial / Generated code doc
lacks reference to ExtensionRegistry
http://code.google.com/p/protobuf/issues/detail?id=241
I first met ExtensionRegistry in an exception
Status: New
Owner: ken...@google.com
Labels: Type-Defect Priority-Medium
New issue 242 by ivan.ko...@gmail.com: Can no longer install protobuf on
pypy
http://code.google.com/p/protobuf/issues/detail?id=242
What steps will reproduce the problem?
1. cd protobuf/python
2. ~/pypy-1.4/bin/pypy
Comment #1 on issue 242 by ivan.ko...@gmail.com: Can no longer install
protobuf on pypy
http://code.google.com/p/protobuf/issues/detail?id=242
If I comment out 'ext_modules = ...' in setup.py and install, it works, and
all of protobuf's unit tests pass.
--
You receiv
Updates:
Status: WorkingAsIntended
Comment #1 on issue 240 by temporal: windows share handling (
\\server\share) bug in protoc compiler
http://code.google.com/p/protobuf/issues/detail?id=240
Import paths should always be relative paths. Use -I (aka --proto_path) to
specify all
Comment #2 on issue 242 by gpsmith: Can no longer install protobuf on pypy
http://code.google.com/p/protobuf/issues/detail?id=242
Yes the extension module is intended to be optional. Conditionally
checking if we should compile the C extension in the setup.py file before
passing ext_modules
Comment #2 on issue 240 by david.vo...@gmail.com: windows share handling (
\\server\share) bug in protoc compiler
http://code.google.com/p/protobuf/issues/detail?id=240
I think You are partly right. We should use relative paths, that's true.
However, windows shares do not work in ne
Updates:
Status: Accepted
Comment #3 on issue 240 by ken...@google.com: windows share handling (
\\server\share) bug in protoc compiler
http://code.google.com/p/protobuf/issues/detail?id=240
I see. I suppose we should avoid converting two leading \'s to /'s.
--
You rec
Updates:
Owner: liuj...@google.com
Comment #3 on issue 242 by ken...@google.com: Can no longer install
protobuf on pypy
http://code.google.com/p/protobuf/issues/detail?id=242
Technically this is a bug report about code that has not yet made it into a
release. Code in SVN is
Status: New
Owner: ken...@google.com
Labels: Type-Defect Priority-Medium
New issue 243 by john.carrino: Improve mergeDelimitedFrom in the java Impl
to setSizeLimit on the CodedInputStream
http://code.google.com/p/protobuf/issues/detail?id=243
CodedInputStream defaults to 64MB size limit
Comment #1 on issue 243 by john.carrino: Improve mergeDelimitedFrom in the
java Impl to setSizeLimit on the CodedInputStream
http://code.google.com/p/protobuf/issues/detail?id=243
I'd like to point out I am referring to the static
CodedInputStream.readRawVarint32(InputStream) and no
Updates:
Status: Accepted
Comment #2 on issue 243 by temporal: Improve mergeDelimitedFrom in the java
Impl to setSizeLimit on the CodedInputStream
http://code.google.com/p/protobuf/issues/detail?id=243
You can destroy the CodedInputStream at the end of each message, and
construct a
Updates:
Status: Accepted
Comment #1 on issue 241 by temporal: Java Tutorial / Generated code doc
lacks reference to ExtensionRegistry
http://code.google.com/p/protobuf/issues/detail?id=241
(No comment was entered for this change.)
--
You received this message because you are
Comment #3 on issue 243 by john.carrino: Improve mergeDelimitedFrom in the
java Impl to setSizeLimit on the CodedInputStream
http://code.google.com/p/protobuf/issues/detail?id=243
The main issue is that there is no way to get the size of the message
because there is no way to do a
Updates:
Status: New
Comment #4 on issue 243 by ken...@google.com: Improve mergeDelimitedFrom in
the java Impl to setSizeLimit on the CodedInputStream
http://code.google.com/p/protobuf/issues/detail?id=243
Woops, for some reason I thought you were talking about C++. Not sure why
Comment #5 on issue 243 by john.carrino: Improve mergeDelimitedFrom in the
java Impl to setSizeLimit on the CodedInputStream
http://code.google.com/p/protobuf/issues/detail?id=243
If the message is over 64MB, the CodedInputStream it creates under the
covers will barf during parsing. So I
Updates:
Status: Accepted
Comment #6 on issue 243 by ken...@google.com: Improve mergeDelimitedFrom in
the java Impl to setSizeLimit on the CodedInputStream
http://code.google.com/p/protobuf/issues/detail?id=243
Ah, I see. You are talking about individual messages over 64MB... for
Comment #7 on issue 243 by john.carrino: Improve mergeDelimitedFrom in the
java Impl to setSizeLimit on the CodedInputStream
http://code.google.com/p/protobuf/issues/detail?id=243
Yeah, this is due to message A having a lot of repeated element B. We
could pull B out of A and into the top
Comment #18 on issue 83 by ken...@google.com: protobuf does not compile
cleanly in 64-bit mode in Visual Studio 2008
http://code.google.com/p/protobuf/issues/detail?id=83
Well that's easy enough. Revision 351.
Leaving the bug open because I don't think this is the only thing peop
Status: New
Owner: ken...@google.com
Labels: Type-Defect Priority-Medium
New issue 244 by kentmchenry: Autogenerated Java code producing
error: "Cannot invoke buildParsed() on the primitive type boolean"
http://code.google.com/p/protobuf/issues/detail?id=244
What steps will rep
Updates:
Status: WontFix
Comment #1 on issue 244 by ken...@google.com: Autogenerated Java code
producing error: "Cannot invoke buildParsed() on the primitive type boolean"
http://code.google.com/p/protobuf/issues/detail?id=244
Your protoc version does not match the
Comment #8 on issue 243 by ev...@mit.edu: Improve mergeDelimitedFrom in the
java Impl to setSizeLimit on the CodedInputStream
http://code.google.com/p/protobuf/issues/detail?id=243
(I'm not a maintainer, but ...) This is recommended by the documentation:
http://code.google.com
Comment #2 on issue 244 by kentmchenry: Autogenerated Java code producing
error: "Cannot invoke buildParsed() on the primitive type boolean"
http://code.google.com/p/protobuf/issues/detail?id=244
@kenton
Using "protoc --version" I realized that I was using the 2.2.0 p
Comment #9 on issue 243 by john.carrino: Improve mergeDelimitedFrom in the
java Impl to setSizeLimit on the CodedInputStream
http://code.google.com/p/protobuf/issues/detail?id=243
Cool, I am down with writing to a stream with a bunch of messages in it. A
useful tool to do so would be the
Comment #10 on issue 243 by ken...@google.com: Improve mergeDelimitedFrom
in the java Impl to setSizeLimit on the CodedInputStream
http://code.google.com/p/protobuf/issues/detail?id=243
How about you define a "header" message which you read first, like:
message Header {
//
Comment #11 on issue 243 by john.carrino: Improve mergeDelimitedFrom in the
java Impl to setSizeLimit on the CodedInputStream
http://code.google.com/p/protobuf/issues/detail?id=243
That's seems like a good way to go. It's protos all the way down.
--
You received this message b
Status: New
Owner: ken...@google.com
Labels: Type-Defect Priority-Medium
New issue 245 by yanghatespam: "index" package conflicts with index
argument name
http://code.google.com/p/protobuf/issues/detail?id=245
If you have:
option java_package = "index";
that wi
Comment #1 on issue 245 by yanghatespam: "index" package conflicts with
index argument name
http://code.google.com/p/protobuf/issues/detail?id=245
This is with svn r93
--
You received this message because you are subscribed to the Google Groups "Protocol
Buffers" gr
Status: New
Owner: ken...@google.com
Labels: Type-Defect Priority-Medium
New issue 246 by yanghatespam: Lots of "warning: [serial] serializable
class ... has no definition of serialVersionUID"
http://code.google.com/p/protobuf/issues/detail?id=246
The generated classes
Comment #1 on issue 246 by yanghatespam: Lots of "warning: [serial]
serializable class ... has no definition of serialVersionUID"
http://code.google.com/p/protobuf/issues/detail?id=246
This is also against svn r92 (no problems with 2.3.0).
--
You received this message becau
Updates:
Status: WontFix
Comment #2 on issue 245 by ken...@google.com: "index" package conflicts
with index argument name
http://code.google.com/p/protobuf/issues/detail?id=245
The Java package naming convention says that the first component of a
package name shoul
Updates:
Status: Accepted
Comment #2 on issue 246 by ken...@google.com: Lots of "warning: [serial]
serializable class ... has no definition of serialVersionUID"
http://code.google.com/p/protobuf/issues/detail?id=246
I think you have the wrong revision number there. r92 is
Comment #3 on issue 245 by yanghatespam: "index" package conflicts with
index argument name
http://code.google.com/p/protobuf/issues/detail?id=245
We've already changed our code (you gave us a good impetus for finally
renaming that poorly named package), but it *is* lega
Comment #3 on issue 246 by yanghatespam: Lots of "warning: [serial]
serializable class ... has no definition of serialVersionUID"
http://code.google.com/p/protobuf/issues/detail?id=246
You're right, I meant r352.
--
You received this message because you are subscribed to th
Comment #4 on issue 245 by ken...@google.com: "index" package conflicts
with index argument name
http://code.google.com/p/protobuf/issues/detail?id=245
"index" is just one of many names that will cause this problem. And
package names are only one kind of problem. I
Comment #5 on issue 245 by yanghatespam: "index" package conflicts with
index argument name
http://code.google.com/p/protobuf/issues/detail?id=245
I didn't mean to document "index" in particular, I meant just a quick note
in the Java docs that proper TLD packag
Updates:
Status: Fixed
Labels: FixedIn-2.4.0
Comment by liuj...@google.com:
Fixed in r353
Affected issues:
issue 166: by_symbol_.insert(iter, make_pair(name, value)); fails with
Sun Studio 12
http://code.google.com/p/protobuf/issues/detail?id=166
issue 167: Python
Updates:
Status: Fixed
Labels: FixedIn-2.4.0
Comment by liuj...@google.com:
Fixed in r354.
Affected issues:
issue 200: Bug on CodedOutputStream.writeEnum
http://code.google.com/p/protobuf/issues/detail?id=200
issue 202: RepeatedField::MoveArray generates "wa
Comment #3 on issue 211 by goo...@thenuthand.com: common.cc calls "abort"
on FATAL messages
http://code.google.com/p/protobuf/issues/detail?id=211
Though better than abort, "throw -1" is not an extremely helpful exception:
it won'y be possible to locate the s
Updates:
Status: Accepted
Owner: liuj...@google.com
Labels: -FixedIn-2.4.0
Comment #4 on issue 211 by temporal: common.cc calls "abort" on FATAL
messages
http://code.google.com/p/protobuf/issues/detail?id=211
Yes, you're right. We should define a
Comment #5 on issue 211 by goo...@thenuthand.com: common.cc calls "abort"
on FATAL messages
http://code.google.com/p/protobuf/issues/detail?id=211
Putting the parameters of the log statement would also be great, or at
least the error message (message_) that was written.
--
Yo
Comment #6 on issue 211 by liuj...@google.com: common.cc calls "abort" on
FATAL messages
http://code.google.com/p/protobuf/issues/detail?id=211
OK, will do.
--
You received this message because you are subscribed to the Google Groups "Protocol
Buffers" group.
To post
Updates:
Status: Accepted
Comment #4 on issue 242 by liuj...@google.com: Can no longer install
protobuf on pypy
http://code.google.com/p/protobuf/issues/detail?id=242
(No comment was entered for this change.)
--
You received this message because you are subscribed to the Google
Updates:
Status: Fixed
Labels: FixedIn-2.4.0
Comment #2 on issue 196 by liuj...@google.com: Python: Ascii output is not
assured to be in utf-8
http://code.google.com/p/protobuf/issues/detail?id=196
Now the text_format.PrintMessage has a parameter "as_utf", which
Comment #2 on issue 225 by liuj...@google.com: Invalid file descriptor
error only with VC++ 2005-2008 (not 2010)
http://code.google.com/p/protobuf/issues/detail?id=225
Hmm, do you mean the question marks or the quotes?
--
You received this message because you are subscribed to the Google
Comment #3 on issue 225 by flio...@free.fr: Invalid file descriptor error
only with VC++ 2005-2008 (not 2010)
http://code.google.com/p/protobuf/issues/detail?id=225
Oups! It's the "question mark" of course. The sign of the Sphinx if you
prefer. ;)
--
You received this mess
Status: New
Owner: ken...@google.com
Labels: Type-Defect Priority-Medium
New issue 247 by compuwarescc: Ability to redirect file output to stdout
http://code.google.com/p/protobuf/issues/detail?id=247
Unable to output source to stdout.
Being able to receive output to stdout rather than just as
Comment #1 on issue 247 by moofish32: Ability to redirect file output to
stdout
http://code.google.com/p/protobuf/issues/detail?id=247
I think this would be a very beneficial enhancement for the same reason.
Solves any concerns over permissions in the unix environment.
--
You received
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 248 by ryan.drake.08: protobuf will not compile without thread
library
http://code.google.com/p/protobuf/issues/detail?id=248
What steps will reproduce the problem?
1. Compile the library without WIN32 or HAVE_PTHREAD
2
Comment #1 on issue 248 by ryan.drake.08: protobuf will not compile without
thread library
http://code.google.com/p/protobuf/issues/detail?id=248
Note, these stubs are enough to compile protobuf-lite. Not sure if more are
needed for the full library.
--
You received this message because
Updates:
Status: Fixed
Labels: FixedIn-2.4.0
Comment by liuj...@google.com:
Fixed in r356
Affected issues:
issue 165: can not link for mips architecture
http://code.google.com/p/protobuf/issues/detail?id=165
issue 211: common.cc calls "abort" on FATAL message
Comment #8 on issue 211 by goo...@thenuthand.com: common.cc calls "abort"
on FATAL messages
http://code.google.com/p/protobuf/issues/detail?id=211
Looks good. Thank you.
--
You received this message because you are subscribed to the Google Groups "Protocol
Buffers" gr
Updates:
Status: Accepted
Owner: ken...@google.com
Comment #2 on issue 248 by ken...@google.com: protobuf will not compile
without thread library
http://code.google.com/p/protobuf/issues/detail?id=248
Hmm. I don't think we should automatically fall back to thread-ho
Updates:
Status: Accepted
Labels: -FixedIn-2.4.0
Comment #3 on issue 196 by ken...@google.com: Python: Ascii output is not
assured to be in utf-8
http://code.google.com/p/protobuf/issues/detail?id=196
Jisi, I'm not convinced that this is fixed. The as_utf parameter s
Comment #2 on issue 247 by ken...@google.com: Ability to redirect file
output to stdout
http://code.google.com/p/protobuf/issues/detail?id=247
What happens if multiple files are generated? For example, if you
have "option java_multiple_files = true;" in your .proto file.
Updates:
Status: Fixed
Labels: FixedIn-2.4.0
Comment by liuj...@google.com:
Fixed in r358
Affected issues:
issue 223: Python Package Doesn't Contain Compiler Plugin Module
http://code.google.com/p/protobuf/issues/detail?id=223
issue 224: Protobuf installation err
Updates:
Status: New
Comment #2 on issue 179 by ken...@google.com: Visual C++ error C1091 when
compiling protoc generated code with over 64k descriptor
http://code.google.com/p/protobuf/issues/detail?id=179
This proves complicated to fix, because we have lots of code that passes
Updates:
Cc: liuj...@google.com
Comment #13 on issue 210 by liuj...@google.com: Java code should detect
incompatible runtime library version
http://code.google.com/p/protobuf/issues/detail?id=210
Hmm, not very clear about the maven version compatibility... So suppose you
have a
Comment #14 on issue 210 by aantono: Java code should detect incompatible
runtime library version
http://code.google.com/p/protobuf/issues/detail?id=210
It would if you specify, what Maven calls, a range -> [1.0,2.0), which
would basically read that anything inclusive between 1.0 and
Comment #4 on issue 196 by liuj...@google.com: Python: Ascii output is not
assured to be in utf-8
http://code.google.com/p/protobuf/issues/detail?id=196
I see, this was actually fixed by another CL that always encodes unicode
string field to utf8 to fix this bug in our internal branch(s
Comment #3 on issue 179 by iiro.hie...@gmail.com: Visual C++ error C1091
when compiling protoc generated code with over 64k descriptor
http://code.google.com/p/protobuf/issues/detail?id=179
OK, thanks! It might be a good idea to write down this limitation into
documentation.
--
You
Comment #3 on issue 247 by compuwarescc: Ability to redirect file output to
stdout
http://code.google.com/p/protobuf/issues/detail?id=247
To be honest I had not considered that scenario. Perhaps breaking this
into two feature requests would be more appropriate...
1) Command line flag
Comment #3 on issue 248 by liuj...@google.com: protobuf will not compile
without thread library
http://code.google.com/p/protobuf/issues/detail?id=248
Hmm, what OS/platform are you using? Common platforms should define
HAVE_PTHREAD.. Maybe it's the acx_pthread.m4 problem..
-
Status: New
Owner: ken...@google.com
Labels: Type-Defect Priority-Medium
New issue 249 by osfan6313: Default values are not assumed to be filled in.
http://code.google.com/p/protobuf/issues/detail?id=249
What steps will reproduce the problem?
1. Create a protocol buffer file with a required
Updates:
Status: WorkingAsIntended
Owner: jas...@google.com
Comment #1 on issue 249 by jas...@google.com: Default values are not
assumed to be filled in.
http://code.google.com/p/protobuf/issues/detail?id=249
This is a common point of confusion. required means a field must be
Comment #4 on issue 248 by ryan.drake.08: protobuf will not compile without
thread library
http://code.google.com/p/protobuf/issues/detail?id=248
Brew mobile platform, with the RVCT4.0 ARM compiler.
I think HAVE_PTHREAD should be around all code blocks that require
pthread.h, but I agree
Comment #15 on issue 210 by ken...@google.com: Java code should detect
incompatible runtime library version
http://code.google.com/p/protobuf/issues/detail?id=210
Urgh, this is problematic. When people declare a dependency on protocol
buffers, I want them to be able to use the version
Comment #5 on issue 248 by poftwaresatent: protobuf will not compile
without thread library
http://code.google.com/p/protobuf/issues/detail?id=248
For what it's worth, I'm running into this on OS X 10.6.5 with up-to-date
macports and protobuf svn rev 358. The configure script do
Comment #6 on issue 248 by poftwaresatent: protobuf will not compile
without thread library
http://code.google.com/p/protobuf/issues/detail?id=248
Looks like r353 broke the m4 code that checks for pthread/sharedlib
coexistance on OS X. Somehow m4/acx_pthread.m4 ends up injecting -Wl,-z,foo
Updates:
Status: Accepted
Owner: liuj...@google.com
Labels: -FixedIn-2.4.0
Comment #13 on issue 188 by liuj...@google.com: protobuf fails to link
after compiling with LDFLAGS="-Wl,--as-needed" because of missing -lpthread
http://code.google.com/p/protobuf/iss
Comment #7 on issue 248 by liuj...@google.com: protobuf will not compile
without thread library
http://code.google.com/p/protobuf/issues/detail?id=248
Yes, the r353 fix isn't correct. Rolled it back at r360.
--
You received this message because you are subscribed to the Google G
Updates:
Status: NeedPatchFromUser
Comment #14 on issue 188 by liuj...@google.com: protobuf fails to link
after compiling with LDFLAGS="-Wl,--as-needed" because of missing -lpthread
http://code.google.com/p/protobuf/issues/detail?id=188
Hi, xarthisius.kk,
The line above: A
Comment #2 on issue 249 by osfan6313: Default values are not assumed to be
filled in.
http://code.google.com/p/protobuf/issues/detail?id=249
Ah. Well I haven't seen any information which ever said that; the
documentation is rather lacking in that regard.
It would be nice to have th
Comment #3 on issue 249 by mdpo...@troilus.org: Default values are not
assumed to be filled in.
http://code.google.com/p/protobuf/issues/detail?id=249
The behavior and documentation seem clear to me: "required" means the user
must set it to something (i.e. it is required).
Comment #4 on issue 249 by osfan6313: Default values are not assumed to be
filled in.
http://code.google.com/p/protobuf/issues/detail?id=249
We're using protocol buffers to store user settings, so we want some fields
to be required(for data validation purposes). However, when we
Comment #5 on issue 249 by jas...@google.com: Default values are not
assumed to be filled in.
http://code.google.com/p/protobuf/issues/detail?id=249
It sounds like there is still some confusion over the meaning of "set."
It is always legal to access a field from a protobuf, whe
Comment #15 on issue 188 by monty.taylor: protobuf fails to link after
compiling with LDFLAGS="-Wl,--as-needed" because of missing -lpthread
http://code.google.com/p/protobuf/issues/detail?id=188
FWIW, we're seeing this in building Drizzle for Ubuntu Natty (and only
there
Comment #16 on issue 188 by liuj...@google.com: protobuf fails to link
after compiling with LDFLAGS="-Wl,--as-needed" because of missing -lpthread
http://code.google.com/p/protobuf/issues/detail?id=188
Hmm, could you please share how you fixed this for Drizzle? explicitly
adding
Comment #17 on issue 188 by xarthisius.kk: protobuf fails to link after
compiling with LDFLAGS="-Wl,--as-needed" because of missing -lpthread
http://code.google.com/p/protobuf/issues/detail?id=188
How about checking for the situation I've described in c#6 ?
Attachments:
Comment #18 on issue 188 by xarthisius.kk: protobuf fails to link after
compiling with LDFLAGS="-Wl,--as-needed" because of missing -lpthread
http://code.google.com/p/protobuf/issues/detail?id=188
Wrong patch...
Attachments:
protobuf-2.3.0-acx_pthread.patch 2.5 KB
--
Yo
Comment #19 on issue 188 by monty.taylor: protobuf fails to link after
compiling with LDFLAGS="-Wl,--as-needed" because of missing -lpthread
http://code.google.com/p/protobuf/issues/detail?id=188
The following patch (which I believe came from Gentoo -
http://bugs.gentoo.org/show_
Comment #20 on issue 188 by liuj...@google.com: protobuf fails to link
after compiling with LDFLAGS="-Wl,--as-needed" because of missing -lpthread
http://code.google.com/p/protobuf/issues/detail?id=188
Thanks Xarthisius and Monty.
Xarthisius, your patch seems to be examining i
Comment #21 on issue 188 by xarthisius.kk: protobuf fails to link after
compiling with LDFLAGS="-Wl,--as-needed" because of missing -lpthread
http://code.google.com/p/protobuf/issues/detail?id=188
I think if the -nostdlib is actually set in the CFLAGS before running the
acx_pthr
Comment #22 on issue 188 by liuj...@google.com: protobuf fails to link
after compiling with LDFLAGS="-Wl,--as-needed" because of missing -lpthread
http://code.google.com/p/protobuf/issues/detail?id=188
I see, so how did you set the nostdlib flag? Is this issue due to the
nostdl
Comment #23 on issue 188 by xarthisius.kk: protobuf fails to link after
compiling with LDFLAGS="-Wl,--as-needed" because of missing -lpthread
http://code.google.com/p/protobuf/issues/detail?id=188
I see, so how did you set the nostdlib flag?
I'm confused. -nostdlib is used by
Comment #24 on issue 188 by liuj...@google.com: protobuf fails to link
after compiling with LDFLAGS="-Wl,--as-needed" because of missing -lpthread
http://code.google.com/p/protobuf/issues/detail?id=188
So I assumed the --as-needed in LDFLAGS is used in the acx_pthread.m4, if
not,
Comment #25 on issue 188 by liuj...@google.com: protobuf fails to link
after compiling with LDFLAGS="-Wl,--as-needed" because of missing -lpthread
http://code.google.com/p/protobuf/issues/detail?id=188
Ah.. Ok, so your fix looks good. Thanks!
--
You received this message becau
Updates:
Status: Fixed
Labels: FixedIn-2.4.0
Comment #5 on issue 196 by ken...@google.com: Python: Ascii output is not
assured to be in utf-8
http://code.google.com/p/protobuf/issues/detail?id=196
Cool, it sounds like it is indeed fixed.
--
You received this message because
Updates:
Status: Accepted
Labels: -Type-Defect Type-Enhancement
Comment #4 on issue 247 by ken...@google.com: Ability to redirect file
output to stdout
http://code.google.com/p/protobuf/issues/detail?id=247
We do already have the ability to output to a jar file. I suppose
Comment #8 on issue 248 by ken...@google.com: protobuf will not compile
without thread library
http://code.google.com/p/protobuf/issues/detail?id=248
To be clear, the warning printed by configure (for v2.3.0 and earlier) is
bogus. It's a side effect of a deeper bug in the m4 file
Comment #26 on issue 188 by liuj...@google.com: protobuf fails to link
after compiling with LDFLAGS="-Wl,--as-needed" because of missing -lpthread
http://code.google.com/p/protobuf/issues/detail?id=188
Hi, Kacper,
Before we can accept this patch, we need you to sign the C
Updates:
Status: Fixed
Labels: FixedIn-2.4.0
Comment #4 on issue 225 by liuj...@google.com: Invalid file descriptor
error only with VC++ 2005-2008 (not 2010)
http://code.google.com/p/protobuf/issues/detail?id=225
Fixed in r362
--
You received this message because you are
Comment #27 on issue 188 by xarthisius.kk: protobuf fails to link after
compiling with LDFLAGS="-Wl,--as-needed" because of missing -lpthread
http://code.google.com/p/protobuf/issues/detail?id=188
Sorry but it's getting ridiculous. That electronic form g
Comment #28 on issue 188 by lukejr2005: protobuf fails to link after
compiling with LDFLAGS="-Wl,--as-needed" because of missing -lpthread
http://code.google.com/p/protobuf/issues/detail?id=188
Just BSD license the patch. Never heard of a company that refuses to use
BSD lic
Comment #29 on issue 188 by temporal: protobuf fails to link after
compiling with LDFLAGS="-Wl,--as-needed" because of missing -lpthread
http://code.google.com/p/protobuf/issues/detail?id=188
Kacper,
Believe me, if we didn't have to ask you to do this, we wouldn't. We
Comment #30 on issue 188 by ken...@google.com: protobuf fails to link after
compiling with LDFLAGS="-Wl,--as-needed" because of missing -lpthread
http://code.google.com/p/protobuf/issues/detail?id=188
(Arg, posted from wrong account again; I always do that when I'm at h
Comment #31 on issue 188 by xarthisius.kk: protobuf fails to link after
compiling with LDFLAGS="-Wl,--as-needed" because of missing -lpthread
http://code.google.com/p/protobuf/issues/detail?id=188
For comparison, the Free Software Foundation has...
I've contributed to sever
Comment #32 on issue 188 by ken...@google.com: protobuf fails to link after
compiling with LDFLAGS="-Wl,--as-needed" because of missing -lpthread
http://code.google.com/p/protobuf/issues/detail?id=188
It looks like our CLA form may in fact be broken. :( I'll try to get it
Comment #33 on issue 188 by ken...@google.com: protobuf fails to link after
compiling with LDFLAGS="-Wl,--as-needed" because of missing -lpthread
http://code.google.com/p/protobuf/issues/detail?id=188
The issue should be fixed now. Sounds like it's too late, though. :(
Comment #34 on issue 188 by xarthisius.kk: protobuf fails to link after
compiling with LDFLAGS="-Wl,--as-needed" because of missing -lpthread
http://code.google.com/p/protobuf/issues/detail?id=188
I've signed the CLA.
Best regards,
Kacper Kowalik
--
You received this message
Comment #8 on issue 60 by mer...@google.com: Support static values
in .proto files
http://code.google.com/p/protobuf/issues/detail?id=60
I've been wishing for this once in a while.
There's a workaround: Protobuf actually does have a syntax for literal
values: field defaults.
601 - 700 of 2413 matches
Mail list logo
