I'm a bit concerned about setting arbitrary proto compiler via
environment variables. Protobuf runtime library requires exactly
matching protoc generated classes to work. Separating the protoc and
library potentially increased the risk of having incompatibility
errors. Not sure if this would bring
OK, it turns out we will use whatever protoc in the PATH as a fail
over. This change is probably fine then.
Sent you a code review. Also add a warning message if the protoc is
set via env variable.
On Thu, Mar 24, 2011 at 5:48 PM, Pherl Liu liuj...@google.com wrote:
I'm a bit concerned about
Updates:
Status: Accepted
Owner: liuj...@google.com
Comment #1 on issue 272 by liuj...@google.com: protobuf-2.3.0 and greater
don't cross-compile
http://code.google.com/p/protobuf/issues/detail?id=272
(No comment was entered for this change.)
--
You received this message
Comment #2 on issue 271 by ask...@gmail.com: RPATH on python native library
is not set correctly
http://code.google.com/p/protobuf/issues/detail?id=271
Even better would to be to not set RPATH at all unless explicitly
requested. Certainly, there should be an option to disable it.
--
You
You can find the algorithm in source code.
http://code.google.com/p/protobuf/source/browse/trunk/src/google/protobuf/compiler/java/java_helpers.cc
On Wed, Mar 16, 2011 at 2:42 PM, Ravi ravikumarkulan...@gmail.com wrote:
Hi Thanks a lot for your time.
Yes the approach looks very clean as the
Looks like pthread library is missing. This should have been covered
by the acx_pthread.m4 script. Could you please try to manually run the
linker(the g++ line you pasted in email), by adding extra -pthread
and/or -lpthread parameters?
On Thu, Mar 10, 2011 at 3:42 AM, Evol mverre...@gmail.com
Please also take a look at the config.log file, generated after
running ./configure, in the project root directory; search for
checking for pthreads library
checking whether pthreads work without any flags
There should be a line, after debug info, saying result: no or result: yes
From your error
Comment #11 on issue 248 by liuj...@google.com: protobuf will not compile
without thread library
http://code.google.com/p/protobuf/issues/detail?id=248
We do have a draft here see http://codereview.appspot.com/3540041/
From the review comments, the blocking issue is
We never actually chose to use cdecl; it was simply the default used by
MSVC. This whole idea that the programmer should have to choose between
calling conventions is a bit strange and inconvenient. The
LIBPROTOBUF_EXPORT annotations are annoying enough; I hope we don't have to
litter our code
