We currently have an issue with a bad interaction between a BSP "feature" from one vendor and the rest of OE, which causes many builds to fail. It seems we have the workaround for it now, but I am not 100% sure yet. If we fail here, I'll request help from you, ok?
OpenEmbedded toolchain for OpenPLi7 3.x kernels
Started by A.A., 13 Dec 2018 16:08
53 replies to this topic
Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #41
-
- PLi® Core member
- 46,960 posts
+541
Excellent
Posted 22 December 2018 - 09:43
* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.
Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #42
-
- PLi® Core member
- 8,458 posts
+327
Excellent
Posted 22 December 2018 - 10:01
The real problem that we are having, is duet to the way we build images with shared libc headers.
We choose to use "shared feeds" and common libc headers for all.
So we do not build different mipsel feeds, different arm-cortexa feeds etc.
Having per vendor feeds or per machine feeds would require much much more bandwidth and build time.
We choose to use "shared feeds" and common libc headers for all.
So we do not build different mipsel feeds, different arm-cortexa feeds etc.
Having per vendor feeds or per machine feeds would require much much more bandwidth and build time.
Edited by athoik, 22 December 2018 - 10:01.
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916
Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #43
-
- PLi® Core member
- 46,960 posts
+541
Excellent
Posted 22 December 2018 - 10:13
I guess some of our collegues do it that way. I see it as a blunt workaround for the stupid errors vendors make in their BSP's every now and then. Until now we've managed to sort it all out, which, imho, is preferrable, but takes quite a bit of time and effort.
And that's where, in the end, the effort goes into, instead of always having master/HEAD of OE.
There is no option to have an arch/group for every vendor, just arch and machine, so if one would choose to switch, every machine would have it's own feeds including glibc. For about 70 machines, that's huge and also a nightmare to build.
* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.
Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #44
-
- Senior Member
- 391 posts
+8
Neutral
Posted 22 December 2018 - 11:53
I see,
can you point me to the toxic layer/recipe?
A.A.
Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #45
-
- PLi® Core member
- 46,960 posts
+541
Excellent
Posted 22 December 2018 - 12:58
Let's wait a while, it may have been solved now. We need a couple of build runs to be sure that it's really solved now.
It has to do with one vendor supplying it's own (newer) glibc (precompiled, from sumo) for some binaries for some of their machines. Now bitbake will see in this package a provides for glibc and in some cases it will use it for dependency linking, also on other models, even from other vendors. Now we have several packages in the feed, for machines that happen to have the same arch, that have a dependency on this vendor's "special glibc", which is of course wrong.
My proposed solution is to have the vendor add a "COMPATIBLE_MACHINE" line in that package that specifies the two machines where this package is required. We're testing this now and seems to work. Fingers crossed.
It's a nice example of our challenges, vendors tend to test their changes in a limited environment that only contains their own machines.
* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.
Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #46
-
- PLi® Core member
- 68,614 posts
+1,739
Excellent
Posted 22 December 2018 - 17:03
My proposed solution is to have the vendor add a "COMPATIBLE_MACHINE" line in that package that specifies the two machines where this package is required. We're testing this now and seems to work. Fingers crossed.
p.s. I have reverted the change we made in the develop BSP to test this, we can't keep building with a locally changed BSP.
Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)
Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.
Many answers to your question can be found in our new and improved wiki.
Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #47
-
- Senior Member
- 391 posts
+8
Neutral
Posted 23 December 2018 - 00:43
Well, back on topic, the culprit of the failing build with musl is linux-3.13-gcc-4.9.3-build-error-fixed.patch
It did not consider musl, I did fix it this way but probably the check about version must be removed alltogether.
GCC_VERSION = $(shell $(CC) --version | grep -e ^mipsel-oe-linux-gcc -e ^mipsel-oe-linux-musl-gcc | sed ...etc etc
I will fork and update the patches.
Cheers
A.A.
Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #48
-
- PLi® Core member
- 46,960 posts
+541
Excellent
Posted 23 December 2018 - 09:54
What is musl?
* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.
Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #49
-
- PLi® Core member
- 46,960 posts
+541
Excellent
Posted 23 December 2018 - 09:54
My proposed solution is to have the vendor add a "COMPATIBLE_MACHINE" line in that package that specifies the two machines where this package is required. We're testing this now and seems to work. Fingers crossed.
p.s. I have reverted the change we made in the develop BSP to test this, we can't keep building with a locally changed BSP.
Is there alreay a PR out?
* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.
Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #50
-
- PLi® Core member
- 68,614 posts
+1,739
Excellent
Posted 23 December 2018 - 12:49
What is musl?
musl provides a libc alternative.
Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)
Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.
Many answers to your question can be found in our new and improved wiki.
Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #51
-
- Senior Member
- 62 posts
0
Neutral
Posted 23 December 2018 - 22:38
Thanks for Openpli 7 on Vu+ Dou working very well
User interface is missing "enable volume control with arrow buttons"
Edited by ghuss, 23 December 2018 - 22:39.
Vu+ Duo 2
Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #52
-
- Senior Member
- 62 posts
0
Neutral
Posted 23 December 2018 - 22:41
Thanks for Openpli 7 on Vu+ Dou working very well
Customize is missing "disable background scanning" openpli 7
Vu+ Duo 2
Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #53
-
- Senior Member
- 62 posts
0
Neutral
Posted 23 December 2018 - 22:58
Thanks for Openpli 7 on Vu+ Dou working very well
Customize is missing "disable background scanning" openpli 7
Sloved by using expert mode
Vu+ Duo 2
Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #54
-
- Senior Member
- 62 posts
0
Neutral
Posted 23 December 2018 - 23:00
Thanks for Openpli 7 on Vu+ Dou working very well
User interface is missing "enable volume control with arrow buttons"
Sloved by using expert mode
Vu+ Duo 2
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
