Stripping out the use of file descriptors and iostreams should be easy.  All
you have to do is remove the relevant classes from
zero_copy_stream_impl.{h,cc} and the corresponding methods from
message.{h,cc}.  The rest of the library doesn't depend on these.  Note that
protoc needs them, but presumably you will only run protoc on your build
machines, not on the target platform itself.
I had an idea yesterday:  We could define a new superclass of
protobuf::Message called protobuf::LeanMessage.  It would only have basic
serialization methods -- no descriptors or reflection.  It could then live
in a separate libprotobuf-lean library that contains only the I/O stuff and
the LeanMessage interface.  Then we could add an option to protoc which
outputs code that only implements this new "lean" interface.  Hopefully this
new library would be far smaller than the current 870k

On Fri, Feb 27, 2009 at 10:58 AM, Tim <> wrote:

> That's precisely the case I've been hoping to make in my current work.
> Since it's a static library to us, the point of stripping down isn't
> so much for reduced footprint (our linker should eliminate the unused
> modules anyway), but instead to simplify the porting effort.
> One of the first things I did was to get libprotobuf 2.0.3 to "build"
> in our environment (Freescale Codewarrior for PPC). But I did this in
> a very incomplete way - just pulling in the missing headers from
> Cygwin - hoping to get a feel for what the problem areas were. These
> were the missing headers:
> include/
>  _ansi.h
>  fcntl.h
>  newlib.h
>  machine/
>    _types.h
>    ieeefp.h
>    types.h
>  sys/
>    _types.h
>    config.h
>    fcntl.h
>    features.h
>    lock.h
>    stat.h
>    types.h
>    unistd.h
> We would of course have to port most of the dependencies to our OS.
> But some of these dependencies are things our system may never
> support. For example, we don't currently support files and streams, or
> exceptions. Our application really only needs the data object
> serialization functionality, and the buffer/string interface is
> sufficient. I thought that, like protobuf-c, there might there a past
> release that would be a better starting point for stripping down
> libprotobuf. But from what I can tell, it looks like even the initial
> release supports files and streams. Pretty basic stuff in most
> environments. I realize we are an exception here.
> After briefly evaluating protobuf and protobuf-c, I can see that we
> would have to heavily modify either one to achieve our goal. Given
> this, I would like to lean towards stripping/modifying the c++
> version, since our app is largely in c++ and this language might
> facilitate our design modifications/extensions. Might you have any
> recommendations or comments on an approach for stripping protobuf of
> file and stream support?
> Given our simple requirements and the perceived work involved with
> stripping libprotobuf, however, my instinct tells me that protobuf-
> c-0.7 would be a better starting point. It already is "stripped". I'm
> guessing we could add the functionality we need there quicker than we
> could strip down from protobuf. Maybe even rewrite it in c++. It's
> only 3 files!
> Comments, anyone?
> On Feb 26, 5:41 pm, Kenton Varda <> wrote:
> > I've tested in on OSX, FreeBSD, and Solaris, but those are not terribly
> > different from Linux.  The Google implementations of protobufs definitely
> > weren't designed for embedded systems, but there might be a case for
> taking
> > the Google C++ implementation and ripping out all the "advanced" features
> to
> > make something extremely stripped-down.
> >
> > On Thu, Feb 26, 2009 at 5:27 PM, Tim <> wrote:
> >
> > > Anyone out there using GPB on an OS other than Linux or Windows? I've
> > > been evaluating GPB for use in an embedded OS and at the moment am a
> > > bit stuck between protobuf and protobuf-c. We would be using GPB for
> > > simple data storage and serialization, and don't need RPC or even
> > > Reflection. I checked out protobuf-c (0.7 is easiest to port, bc it's
> > > before RPC was added) and this is definitely at the opposite end of
> > > the spectrum. We would need to add quite a bit of functionality to it.
> >

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to