[OpenWrt-Devel] protobuf broken in BB

[obconseil]

Hello,


The last patch I sent to Guillaume is working for me. I'm waiting for 
his approval before re-submitting it to the list officially.

Thanks John,




Obinou


Le 17/11/2014 09:54, John Crispin a écrit :
> Hi,
>
> What happened to the testing ? we are considering a 14.07.1 in the very
> near future so this should be fixed beforehand.
>
> 	John
>
> On 05/11/2014 22:43, Guillaume Déflache wrote:
>> 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).
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel