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@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
