Hi, I have built a x86 SATO image in Pyro and able to run the image in * 32-bit Intel PC (This is my actual target) * 64-bit Intel PC (This PC is used for testing the same x86 image) I need to have CEF (Chromium Embedded Framework) to run on this PC as per my application requirement. For this I had to add the following components on top of core-image-sato in local.conf. * libxscrbsaver * cups I have taken the prebuilt binaries (32-bit Linux) from the CEF forum. To begin with I have taken the CEF Client binaries so that I can quickly launch the cefsimple application to verify. Issue noticed: * CEF Client application opens up the browser view and launch the web url without any error in 64-bit PC * CEF Client application fails to load in 32-bit PC Observation on Ubuntu: * Installed Ubuntu i386 image on my 32-bit PC and it runs the CEF Client application without any issues. Possible root cause: I am not sure but I could figure out multiple issues running CEF 32-bit application on Pyro x86 Image. One of them is related to POSIX implementation of file_path which is not resolving the module or application path correctly because of that the CEF application is not able to load its application resources. Verified the same with Morty and Krogoth as well and observed the same behaviour on 32-bit PC. Can somebody help to find correct configuration, if required, to run 32-bit CEF binaries running on 32-bit x86 based PC? -- skumar
Hi There, Can you be more specific about where you got your binaries from? Have you looked at the output of ldd and / or used strace to see if there is some library that is located in a wrong path?
Created attachment 3886 [details] GDB trace
Created attachment 3887 [details] strace output
Hi, The CEF 32-bit binary has been taken from CEF build (12th July 2017). Sample Application - http://opensource.spotify.com/cefbuilds/index.html The Sample Application (Linux 32-bit) archive contains a native application (cefsimple) with all the shared objects. For running on Pyro image (SATO) we need to have the below components included in the image (MACHINE?="genericx86"). IMAGE_INSTALL_append = " libxscrnsaver cups " After these component included in SATO image we should be able to run the cefsimple application (running from the directory where cefsimple exists) which will open up a window with google.com webpage by default. This is happening fine when I run the x86 image on 64-bit PC but not on 32-bit PC. The same application works fine on Ubuntu i386 (16.04) image on 32-bit PC. Error Noticed: Basically when I run cefsimple application it looks for IcuDtl.dat and couple of bin files from the directory where the cefsimple application exists. When running on 64-bit PC it picks up those files perfectly. Example (CEF binaries are extracted to /home/root/cefapp/): $cd /home/root/cefapp/ $./cefsimple When running on 32-bit PC it is looking into a folder name as given below $cd /home/root/cefapp/ $./cefsimple **It looks for all resource files from /home/root/cefapp/cefsimpl/... instead of /home/root/cefapp/... This is very strange that it appends additional folder name(first 8 chars of the main application). This is not happening on 64-bit PC. Also it is not happening with Ubuntu i386 image on 32-bit PC as well. To rid of this error, I have copied the resource files under this additional sub folder "cefsimpl" then it ended up in segmentation fault. Another observation when I run it on 32-bit PC is it creates lot of folders like /h /ho /hom /home /home/r /home/ro /home/roo ... Please find the attached strace and gdb output for the segmentation fault. There is something going wrong with file path extraction. There is a POSIX layer implementation in CEF source for the same. -- skumar
Created attachment 3890 [details] build local.conf
Created attachment 3891 [details] build bblayer.conf
I have tried with both sato and sato-sdk image, the sato-sdk image worked correctly and launched to the google.com webpage, but the sato image failed. One thing I noticed is that my sato image was missing libgtk-x11-2.0.so.0, but yours appears to have one. I rebuilt my core-image-sato with gtk+ added I also added the ldd package and verified that the new image contained all the libraries that cefsimple required. When I ran the updated core-image-sato (genericx86) on my minnow board with 32bit firmware, it worked correctly and did not panic or fail, I also tested this with qemu (using genericx86 machine). I ran this under the extended name that the tarball extracted it to, I also tried copying the Release directory to /home/root/cefapp and both worked correctly. NOTE: I chose NOT to install java on my system, so it's possible this is related to the openjdk. Since openjdk is outside of Poky and the Yocto Project there could be all sorts of other relationship. I will do one more test with OpenJDK, but I will likely close this as works for me. Please try removing OpenJDK in your testing and confirm it it works or fails.
Thanks for helping. Did you run the sato image (genericx86) on 64-bit minnow board? if so then this is expected since i am not facing any problem on running genericx86 sato image with CEF (32-bit) on 64-bit Intel PC. I verified the sato image (genericx86) without openjdk (had to include libgtk as you mentioned in your response) as well and there is no difference in result on 32 bit Intel PC (tested it on two different PCs). But with the same sato image (genericx86) it is working fine on 64-bit Intel PC. So there is no difference in result by removing openjdk. As per the above validation it is clear that it is not an issue with openjdk since sato image (genericx86) with openjdk works fine on 64 bit Intel PC. I guess, there is some issue in the platform level which is preventing this (CEF) 32-bit binaries to run on 32-bit PC. Another observation is the CEF (32-bit) binary is working fine on VirtualBox with the same sato image (genericx86) on a 64-bit PC. So it seems if the underlying physical processor is 64-bit then everything is fine for the genericx86 sato image, but not for the 32-bit processor. -- skumar
OK, glad you also were able to confirm that OpenJDK does not contribute to the issue. Just to be clear the minnowboard can be used in either 32 bit mode or 64 bit mode, depending on which firmware. I tested this in 32bit mode. Your right the processor itself is still a 64bit capable process, I do not have a pure 32bit processor here, but I am checking with other team members who have access to a 32bit cpu.
Thanks for the details. Please update your observation on 32-bit machine. It would be really helpful, if there is any workaround or fix on current version of poky, for me to proceed on the application development using CEF on my 32-bit target. I will also update if there is any workaround found from my side.
I managed to get an old original MinnowBoard (Atom E640 processor - 32bit) up and running. Running the cefsimple binary, I get as far as launching a web browser and trying to load google. I can't confirm whether its 100% working, as I can't seem to get ethernet working on this board, but this seems to be further than you were getting. I also do not see extra directories in / such as /h and /ho. That one sounds like data corruption. This was with master of OE-core. I'll run a build over night with pyro and try again tomorrow.
I guess this is good improvement, as per your observations. Thanks for helping. I would like to understand the difference in my build config with yours. Can you please share the local and bblayer of your build. Are you on master branch of poky https://git.yoctoproject.org/cgit/cgit.cgi/poky/?
Yes, the good result was with the HEAD of master branch of poky. On pyro I am able to reproduce the exact results you are seeing, even what I thought looked like data corruption. local.conf, the only changes from default are: MACHINE ?= "genericx86" IMAGE_INSTALL_append = " libxscrnsaver cups gtk+" IMAGE_ROOTFS_EXTRA_SPACE = "2000000" After it failed on my original minnowboard, I used the exact same installation with my 32bit firmware minnowboard turbot and it was successful, so it is indeed something that only occurs with true 32bit hardware. I'll do a bisect to figure out what changed in master to allow it to work.
Took a while due to most of the image having to rebuild each time, but my bisect shows that this set of commits is where it begins working: fee85d5 gcc: Use ucontext_t instead of ucontext 8cf9059 gcc-sanitizer: Fix build with glibc 2.26 16cb2a0 glibc: Enable obsoleted nsl 8281a70 glibc: Drop obsoleted bits/string.h from multilibbing 1f4f343 glibc: Upgrade to 2.25.90
(In reply to comment #14) > Took a while due to most of the image having to rebuild each time, but my > bisect shows that this set of commits is where it begins working: > > fee85d5 gcc: Use ucontext_t instead of ucontext > 8cf9059 gcc-sanitizer: Fix build with glibc 2.26 > 16cb2a0 glibc: Enable obsoleted nsl > 8281a70 glibc: Drop obsoleted bits/string.h from multilibbing > 1f4f343 glibc: Upgrade to 2.25.90 Thanks for your time and the detailed analysis. I understand the difficulty of figuring this out with multiple image builds. Thanks again.
(In reply to comment #15) > (In reply to comment #14) > > Took a while due to most of the image having to rebuild each time, but my > > bisect shows that this set of commits is where it begins working: > > > > fee85d5 gcc: Use ucontext_t instead of ucontext > > 8cf9059 gcc-sanitizer: Fix build with glibc 2.26 > > 16cb2a0 glibc: Enable obsoleted nsl > > 8281a70 glibc: Drop obsoleted bits/string.h from multilibbing > > 1f4f343 glibc: Upgrade to 2.25.90 > > Thanks for your time and the detailed analysis. I understand the difficulty > of figuring this out with multiple image builds. Thanks again. One query on GCC patches. Poky 2.3.1 still uses GCC 6.3 but the top two patches are on top of GCC7.1. If I want to be in Poky 2.3.1, do I need to switch to GCC7.1 and take those patches?
I found out that the binary runs correctly with the morty branch (with nss added to IMAGE_INSTALL), so I bisected between morty and pyro as well. I found this was the commit where it breaks: [clsulliv@clsulliv poky]$ git bisect good 49fec741ebd62e6a4157e364321b9fec8931825b is the first bad commit commit 49fec741ebd62e6a4157e364321b9fec8931825b Author: Khem Raj <raj.khem@gmail.com> Date: Thu Jan 12 12:20:50 2017 -0800 glibc: Upgrade to 2.25 snapshot glibc 2.25 release is in freeze stage now (From OE-Core rev: b72dbf70646e9dca0dbb5b22bc70d919e6eb8bdc) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> It looks like it is an issue with that version of glibc, and upgrading only that should fixit. Unfortunately, that's out of my realm of expertise and when I tried to do it many things started breaking.
Thank you for your response. I also tried to integrate those changes directly on Pyro and ended up many issues. Now I have two ways, as per your suggestions, till 2.4 comes out 1. Go back to Morty with NSS included 2. Switch to Master with the commit related to glibc and gcc upgrade Currently I am following option 2 and verified CEF and Google-chrome (using meta-brower layer from https://github.com/OSSystems/meta-browser/tree/master/recipes-browser/chromium) successfully. I am hoping that these gcc and glibc upgrade will be included in Poky 2.4. -- skumar
If you are OK using Master (2.4), which will be released in late October, we can close this bug as WONTFIX for 2.3, as we won't backport the GCC and GLIBC changes to 2.3, as this is against the general policy of the Yocto Project and OpenEmbedded core. Please let me know if this is agreeable? Thanks for your patience
Can you update if you are going to move to master/2.4?
(In reply to comment #20) > Can you update if you are going to move to master/2.4? Yes, I will continue on master:87f2328fb271ee34d5102cfdb6d66f97fd5188bd till actual 2.4 release. Thanks for the detailed analysis on this issue.
It appears the question was answered. Please restate the question if this is still NEEDINFO.
Due to the nature of this issue and the extensive backporting that would be required, we are going to mark this as wont fix, the reporter will be moving to 2.4 in order to resolve this.