[OpenWrt-Devel] protobuf broken in BB

Guillaume Déflache guillaume.deflache at ibwag.com
Wed Nov 5 10:41:12 EST 2014


Am 05.11.2014 15:32, schrieb obconseil:
> Hello,
>
> Le 05/11/2014 12:37, Guillaume Déflache a écrit :
>>
>> [As I am not sure Jacob and Obinou (the package's registered maintainer)
>> are the same person (are they?), I am trying to CC to both too...]
>
> No we are not :-)

You were the fastest to respond so you indeed ought to stay the 
maintainer! ;)


>> We are actually trying migrating from a few-months-old trunk snapshot to
>> the official Barrier Breaker release, and on BB protobuf does not work
>> anymore.
>
> I admit I did not checked.

For others' to understand I should have made clear the library itself 
builds fine, only the host's `protoc` does not get installed.


>> A workaround that got protoc to be copied at the right place (and e.g.
>> allowed CMake to find it) was to go to the host build directory and to
>> do a `make install` from here.
>> In other words:
>>      $(MAKE) -C $(HOST_BUILD_DIR) install
>>
>> Did that have to be changed for 2.5.0 (from 2.4.1)? What was the need?
>
> The need was for the compilation of the "seeks" project
> https://beniz.github.io/seeks/ .
> This programs looks unmaintained nowadays.

Probably this package ships a source tarball which includes pregenerated 
Protocol Buffers source files then, which would have hidden the problem.


> I can update protobuf to the latest version, v2.6.0 , that would work
> for you ?

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! :)


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.)


Cheers,
    Guillaume
-- 
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.
http://www.avast.com
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel



More information about the openwrt-devel mailing list