Comment #21 on issue 248 by bschlin...@inbound5.com: protobuf will not
compile without thread library
http://code.google.com/p/protobuf/issues/detail?id=248
Another solution is to use nanopb: http://koti.kapsi.fi/jpa/nanopb/
This worked well for a recent embedded systems project which used
Comment #17 on issue 248 by hazelnu...@gmail.com: protobuf will not compile
without thread library
http://code.google.com/p/protobuf/issues/detail?id=248
Has anybody determined the correct way to build protobuf without depending
on a threading library? I want to use protobuf on a ARM
Comment #18 on issue 248 by ronanpai...@gmail.com: protobuf will not
compile without thread library
http://code.google.com/p/protobuf/issues/detail?id=248
On my ARM Cortex-M3 project I just used protobuf-c and replaced the
malloc() calls with static objects, since only one thread used the
Comment #19 on issue 248 by hazelnu...@gmail.com: protobuf will not compile
without thread library
http://code.google.com/p/protobuf/issues/detail?id=248
Is that code up anywhere so I could check it out? By protobuf-c, you mean
this one right:
https://code.google.com/p/protobuf-c/
It
Comment #14 on issue 248 by eyal.far...@gmail.com: protobuf will not
compile without thread library
http://code.google.com/p/protobuf/issues/detail?id=248
I had a look at the proposed patch, the one that cannot be merged into GPB
release...
Just a thought: once.h is compiled either as part
Comment #15 on issue 248 by ronanpai...@gmail.com: protobuf will not
compile without thread library
http://code.google.com/p/protobuf/issues/detail?id=248
Maybe one can define weak functions that are thread-safe and then the user
may override with functions pertaining to each platform. Or
Comment #13 on issue 248 by ronanpai...@gmail.com: protobuf will not
compile without thread library
http://code.google.com/p/protobuf/issues/detail?id=248
Some platforms simply don't have PTHREADS. Some because they aren't
multithreaded or have unusual OSes (i.e. microcontrollers with RTOS
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
Comment #9 on issue 248 by jonny.de...@googlemail.com: protobuf will not
compile without thread library
http://code.google.com/p/protobuf/issues/detail?id=248
So now I am not sure whether there is a way to build 2.4.0a without pthread
dependency. I would like to use protobuf in a
Comment #10 on issue 248 by ken...@google.com: protobuf will not compile
without thread library
http://code.google.com/p/protobuf/issues/detail?id=248
You will need to modify the protobuf code slightly, but it should be easy.
Find the places that use pthread (there aren't many of them)
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 that
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 Groups
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..
--
You
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 #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 does give me
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: 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-hostile
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
18 matches
Mail list logo
