So, let me explain exactly the problem here...
> $ protoc --cpp_out=. -I../P -I../P/.. ../P/a.proto
> $ protoc --cpp_out=. -I../P -I../P/.. ../P/b.proto
If you were to compile both protos with a single command:
$ protoc --cpp_out=. -I../P -I../P/.. ../P/a.proto ../P/b.proto
Then protoc would give you errors suggesting that "a.proto" and "P/a.proto"
are defining conflicting symbols. This hints at the underlying problem:
protoc cannot tell that the "../P/a.proto" you specified on the command line
is the same as the "P/a.proto" that b.proto is trying to import.
The problem here is that the meaning of ".." is subtle -- if foo is a
symlink, then "foo/bar/.." is NOT necessarily the same as "foo". Therefore,
protoc makes no attempt to collapse ".."s in order to detect when two files
are actually the same file. Instead, it relies only on their canonical name
relative to the import path. Unfortunately, in your case, when you pass
"../P/a.proto" on the command line, protoc concludes that because "../P" is
in the import path, this file's canonical name is "a.proto". But b.proto
imports "P/a.proto", which must be a different file.
What you actually want to do is this:
$ protoc --cpp_out=. -I.. ../P/a.proto
$ protoc --cpp_out=. -I.. ../P/b.proto
In this case, protoc will determine that the canonical names are "P/a.proto"
and "P/b.proto", which match the style you are using in your import
In general, you should never pass overlapping -I flags to protoc. Arguably
protoc should print a warning if you do. Other than that, I'm not sure what
else we could do to detect your problem.
On Tue, Apr 13, 2010 at 11:24 AM, CB <cn...@verizon.net> wrote:
> Workarounds aside, there is still a bug to be fixed.
> If you wish to argue that the .proto files or the -I options I passed
> to proto are invalid, then protoc should have declared an error.
> If you wish to argue that the .proto files and the -I options I passed
> to proto are valid, then the c++ code emitted by protoc should have
> compiled without error.
> If the error was simply an issue of -I options passed to protoc/g++
> that would be one thing, but in this case, protoc generated a call to
> a function that doesn't even exist in the generated code set. That's
> a major bug.
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To post to this group, send email to proto...@googlegroups.com.
> To unsubscribe from this group, send email to
> For more options, visit this group at
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at