Issue 248 in protobuf: protobuf will not compile without thread library
prot...@googlecode.com
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. Observe compiler errors
What is the expected output? What do you see instead?
Expect successful compilation, see "No suitable threading library
available."
Attached a patch (against 2.3.0) that stubs out the pthread and Mutex stuff
if you don't configure HAVE_PTHREAD.
Cheers!
Attachments:
protobuf_nothreads.patch 1.5 KB
prot...@googlecode.com
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.
prot...@googlecode.com
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
code when no threading library is available -- this could cause really
hard-to-debug problems if it happened by accident. But we could certainly
provide a way for the user to explicitly ask for this, e.g. a
--without-thread-safety configure option.
prot...@googlecode.com
Comment #3 on issue 248 by liuj...@google.com: protobuf will not compile
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..
prot...@googlecode.com
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 that you don't want to fall back to unsafe code
unless the user takes affirmative action during configure.
Perhaps keep the HAVE_PTHREAD define and put it around all the pthread
code, and then add --without-thread-safety and make it set some kind of
WITH_STUBBED_THREAD define that would enable the stubs?
prot...@googlecode.com
Comment #5 on issue 248 by poftwaresatent: protobuf will not compile
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 a
warning:
...
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... -D_THREAD_SAFE
checking whether to check for GCC pthread/shared inconsistencies... yes
checking whether -pthread is sufficient with -shared... no
checking whether -lpthread fixes that... no
checking whether -lc_r fixes that... no
configure: WARNING: Impossible to determine how to use pthreads with shared
libraries
...
Strange enough, Darwin does come with /usr/lib/libpthread.dylib and
/usr/include/pthread.h. I'll keep digging, but it's not high on my priority
list. Maybe just need to tweak the configure.ac a bit?
prot...@googlecode.com
Comment #6 on issue 248 by poftwaresatent: protobuf will not compile
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
onto the gcc command line, which Apple's ld chokes on (invalid option -z or
something like that).
Reverting to r352 seems to work around the issue.
prot...@googlecode.com
Comment #7 on issue 248 by liuj...@google.com: protobuf will not compile
http://code.google.com/p/protobuf/issues/detail?id=248
Yes, the r353 fix isn't correct. Rolled it back at r360.
prot...@googlecode.com
Comment #8 on issue 248 by ken...@google.com: protobuf will not compile
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 we're trying
to fix. But basically, you can ignore it.
prot...@googlecode.com
Comment #9 on issue 248 by jonny.de...@googlemail.com: protobuf will not
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 single-threaded embedded
environment, where there is no pthread library. Is this possible? If yes,
how would I invoke "configure" to do this?
prot...@googlecode.com
Comment #10 on issue 248 by ken...@google.com: protobuf will not compile
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) and replace
them with code appropriate for a single-threaded context. You can just
delete the mutex lock/unlock calls. For pthread_once, you'll need to make
the "once" type just contain a boolean flag and have the once-init call
return if the flag is already set, otherwise call the callback and then set
the flag.
If someone wants to write a patch implementing a --without-thread-safety
configure option that does this automatically, go for it...
prot...@googlecode.com
Comment #11 on issue 248 by liuj...@google.com: protobuf will not compile
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
google/protobuf/stubs/once.h needs to include "config.h", which is not
acceptable.
You can actually patch the diff to have a hardcoded no thread-safety
protobuf.
prot...@googlecode.com
Comment #13 on issue 248 by ronan...@gmail.com: protobuf will not
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 or
bare-metal, without OS).
prot...@googlecode.com
Comment #14 on issue 248 by Eyal.Far...@gmail.com: protobuf will not
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 of GPB itself or as part
of generated pb.cc file.
I think the compilation of GPB itself can be handled by adding a configure
option that will add a definition of 'PROTOBUF_WITHOUT_THREAD_SAFETY' to
the CC_FLAGS or config.h.
The second scenario, compilation of a generated pb.cc file can be handled
by an option to the code generator that will define this symbol in the
scope of the pb.cc file (only).
I know that this approach makes room for erroneous situations like
thread-less GPB with a thread-enabled generated classes, but I think there
must be a way to fix this.
is this approach acceptable in any way?
Eyal.
prot...@googlecode.com
Comment #15 on issue 248 by ronan...@gmail.com: protobuf will not
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 separate those
functions in a single file to make the transition easier.
prot...@googlecode.com
Comment #17 on issue 248 by hazelnu...@gmail.com: protobuf will not compile
Has anybody determined the correct way to build protobuf without depending
on a threading library? I want to use protobuf on a ARM Cortex-M4 with an
RTOS that does not provide pthreads.
Do the changes that the original patch made roughly apply to the latest svn
checkout?
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
prot...@googlecode.com
Comment #18 on issue 248 by ronan...@gmail.com: protobuf will not
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 objects
synchronously.
prot...@googlecode.com
Comment #19 on issue 248 by hazelnu...@gmail.com: protobuf will not compile
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 seems like it hasn't been touched in > 2 years.
prot...@googlecode.com
Comment #21 on issue 248 by bschlin...@inbound5.com: protobuf will not
Another solution is to use nanopb: http://koti.kapsi.fi/jpa/nanopb/
This worked well for a recent embedded systems project which used PBs.