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
soonest).
I would have no objections to 2.6.1 if it also works for us too (I can
test that at the same time).
