[OpenWrt-Devel] protobuf broken in BB

Guillaume Déflache guillaume.deflache at ibwag.com
Wed Nov 5 16:43:13 EST 2014

Am 05.11.2014 17:39, schrieb obconseil:
> Le 05/11/2014 16:41, Guillaume Déflache a écrit :
> [...]
>> For others' to understand I should have made clear the library itself
>> builds fine, only the host's `protoc` does not get installed.
>> It would not help, 2.4.1 of AA worked fine, only the Makefile's new host
>> macros cause problems.
>> That patch chunk should be reverted IMHO and only the version changed,
>> in case someone still needs it (we do not).
>> Besides there is 2.6.1 now: in my own experience x.y.n tends to be more
>> stable than z.t.0 for all values of x,y,z,t and n! :)
> I just made a quick build using 2.6.1 from github on the openwrt's trunk.
> I had to remove the patch completely , and make the according changes on
> the Makefile.
> Then it built (host+package) without any issues on my debian jessie (I
> have to indicate here

> that I do not have the libprotobuf nor the libprotobuf-dev  .deb
> packages installed on this machine.

That's indeed better for testing!

> It created me the ./build_dir/host/protobuf-2.6.1/src/protoc without
> issues.

Fine, but that's not the problem as I said before (see the very 1st 
quoted text in this message): *installing protoc at the right location* 
(that is .../build_dir/host/bin/protoc IIRC) is the problem.

I checked that with our pre-BB snapshot it was installed where expected 
and that with the BB release it is not. You can try executing `make 
install` from the host build directory to convince yourself that that 
does what is required from the OpenWrt Makefile but currently missing in 
BB's. That's what I did and then the problem was gone.

So you have to try using protoc to generate some source code files in 
order to really stumble on the problem. Apart from that everything works 
fine indeed.

>> Meanwhile another protobuf-related problem showed up, perhaps someone
>> can help:
>>> [100%] Building CXX object CMakeFiles/[CENSORED].pb.cc.o
>>> /tmp/ccKFaHTE.s: Assembler messages:
>>> /tmp/ccKFaHTE.s:16516: Error: opcode not supported on this
>>> processor:mips1 (mips1) `sync'
>>> make[5]: *** [CMakeFiles/[CENSORED].pb.cc.o] Error 1
>> Since the snapshot we used previously PKG_USE_MIPS16:=0 also got added,
>> does that mean we should also use that on all packages that compile
>> Protocol Buffer generated code and/or link with the PB library?
>> Or is it necessary/possible to instruct the host protoc to generate
>> source code for MIPS32? Does PB needs generating CPU-specific C/C++
>> (instrinsics?) or asm sections?
>> (We do not need MIPS16 ATM, so any MIPS32 solution would do for us.)
> The target platform I'm using now is Ralink RT5350 , so mips24k , is
> that OK for you ?

I currently develop for the ZyXEL NBG6716 
(<http://wiki.openwrt.org/toh/zyxel/zyxel_nbg6716>) which is MIPS32 
(MIPS74Kc). Would that happen to be backward compatible with yours?

> I don't really understand why you have such an error - it look like a
> compiler error rather than a protobuf error.

Indeed, but I could upgrade many packages from our pre-BB snapshot to 
the BB release without changing a single compiler flag or source code 
line WRT MIPS16. Then today I just had a problem while compiling the 1st 
PB-generated source code file... Just saying! ;)

Anyway I will try to force PKG_USE_MIPS16:=0 on related packages to see 
if it helps and report here.

> I have yet to build the package with a mips16 target.
> Anyway, the patch I used is joined to this mail - if it's OK with you
> I'll resend the patch with an official pull-request header.

Sorry, the patch as it stands still would not solve our problem. 
Reverting the non-version related changes compared to pre-BBfinal 
pre-Git revisions would, I think (I can test that next Friday at the 
I would have no objections to 2.6.1 if it also works for us too (I can 
test that at the same time).

ibw ag software, Aarestrasse 17, CH-5412 Vogelsang, http://www.ibwag.com
Guillaume Déflache, Projektingenieur, Telefon: +41 56 201 07 30

Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv.
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list