eglplatform.h: No such file or directory

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

eglplatform.h: No such file or directory

7,724 Views
cetzweiler
Contributor II

Hello,

I get this error when I try to: bitbake fsl-image-gui.

Last week this all built for me.

I had problems and decided to start over.

I did the following:

cd  fsl-community-bsp/

rm -rf *

repo sync

Now, it does not build.

Can you help me figure out what to do?

Here is my repo init:

repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b dora

Here is my local.conf:

MACHINE ??= 'imx6dlsabresd'
DISTRO ?= "poky"
PACKAGE_CLASSES ?= "package_rpm"

EXTRA_IMAGE_FEATURES = "debug-tweaks ssh-server-openssh"

USER_CLASSES ?= "buildstats image-mklibs image-prelink"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS = "\
    STOPTASKS,${TMPDIR},1G,100K \
    STOPTASKS,${DL_DIR},1G,100K \
    STOPTASKS,${SSTATE_DIR},1G,100K \
    ABORT,${TMPDIR},100M,1K \
    ABORT,${DL_DIR},100M,1K \
    ABORT,${SSTATE_DIR},100M,1K"

BB_NUMBER_THREADS = '8'
PARALLEL_MAKE = '-j 8'

DL_DIR ?= "${BSPDIR}/downloads/"
ACCEPT_FSL_EULA = ""
ACCEPT_FSL_EULA_mx6 = "1"

CONF_VERSION = "1"

Here is a snippet that includes my error:

| make[1]: Leaving directory `/home/chuck/work/jungo/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/mesa/2_9.1.6-r0/build'
| sed: can't read /home/chuck/work/jungo/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/mesa/2_9.1.6-r0/image/usr/include/EGL/eglplatform.h: No such file or directory
| WARNING: /home/chuck/work/jungo/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/mesa/2_9.1.6-r0/temp/run.do_install.5255:1 exit 2 from
|   sed -i -e 's/^#ifdef MESA_EGL_NO_X11_HEADERS/#if 0/' /home/chuck/work/jungo/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/mesa/2_9.1.6-r0/image/usr/include/EGL/eglplatform.h
| ERROR: Function failed: do_install (log file is located at /home/chuck/work/jungo/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/mesa/2_9.1.6-r0/temp/log.do_install.5255)
ERROR: Task 3199 (/home/chuck/work/jungo/fsl-community-bsp/sources/poky/meta/recipes-graphics/mesa/mesa_9.1.6.bb, do_install) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1729 tasks of which 1174 didn't need to be rerun and 1 failed.

Thank you,

Chuck

Labels (3)
16 Replies

3,374 Views
app025
Contributor III

Hi all,

it looks like that the problem raised upon the following commit on dora branch of poky:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dora&id=d04d0c07355b40dc2f2f71548526d9bb741...

Thi commit changed the way the eglplatform.h is patched, however this file is nota available for iMX6: in dora the bbappend we have in meta-fsl-arm disable the egl support.

IMHO, there are two possible solutions:

1) check the the file presence before calling the "sed" command

2) call the "sed" command on the original file before install it

Actually I'm not sure about which is the right solution, but in my case I just applied the following patch (solution 2) to mesa recipe:

============================================================================

diff --git a/meta/recipes-graphics/mesa/mesa_9.1.6.bb b/meta/recipes-graphics/mesa/mesa_9.1.6.bb

index 6e9cd82..edaf21c 100644

--- a/meta/recipes-graphics/mesa/mesa_9.1.6.bb

+++ b/meta/recipes-graphics/mesa/mesa_9.1.6.bb

@@ -17,8 +17,8 @@ S = "${WORKDIR}/Mesa-${PV}"

#because we cannot rely on the fact that all apps will use pkgconfig,

#make eglplatform.h independent of MESA_EGL_NO_X11_HEADER

-do_install_append() {

+do_install_prepend() {

     if ${@base_contains('PACKAGECONFIG', 'egl', 'true', 'false', d)}; then

-        sed -i -e 's/^#ifdef MESA_EGL_NO_X11_HEADERS/#if ${@base_contains('DISTRO_FEATURES', 'x11', '0', '1', d)}/' ${D}${includedir}/EGL/eglplatform.h

+        sed -i -e 's/^#ifdef MESA_EGL_NO_X11_HEADERS/#if ${@base_contains('DISTRO_FEATURES', 'x11', '0', '1', d)}/' ${S}/include/EGL/eglplatform.h

     fi

-}

\ No newline at end of file

+}

============================================================================

Hope to be useful for somebody.

Best Regards

Gigi

0 Kudos

3,374 Views
cetzweiler
Contributor II

Gigi,

Thank you for posting this.

I have applied your patch and this works for me.

Nice work-around until someone fixes this issue.

Chuck

0 Kudos

3,374 Views
app025
Contributor III

Hi Chuck,

I'm discussing the problem on meta-freescale mailing list and Ronaldo Nunez proposed a more reasonable patch that I hope will be pushed asap to dora branch of meta-fsl-arm repository.

Here you are Ronaldo's patch:

============================================================================

diff --git a/recipes-graphics/mesa/mesa_9.1.6.bbappend b/recipes-graphics/mesa/m

index 9975abc..5255704 100644

--- a/recipes-graphics/mesa/mesa_9.1.6.bbappend

+++ b/recipes-graphics/mesa/mesa_9.1.6.bbappend

@@ -21,6 +21,16 @@ python __anonymous () {

         d.setVar('EXTRA_OECONF', ' '.join(new_extra_oeconf))

+        # Remove egl and gles from PACKAGECONFIG

+        packageconfig = d.getVar('PACKAGECONFIG', True).split()

+        take_out = ['egl', 'gles']

+        new_packageconfig = []

+        for i in packageconfig:

+            if i not in take_out:

+                new_packageconfig.append(i)

+

+        d.setVar('PACKAGECONFIG', ' '.join(new_packageconfig))

+

         # Remove itens from provides

         provides = d.getVar('PROVIDES', True).split()

         take_out = ['virtual/libgles1', 'virtual/libgles2', 'virtual/egl']

============================================================================

Regards

Gigi

3,374 Views
cetzweiler
Contributor II

Thank you again Gigi,

This also works for me.

I'll take your word for it that this is a better work-around, as I am not knowledgeable enough.

Chuck

0 Kudos

3,374 Views
YixingKong
Senior Contributor IV

Chuck

This discussion is closed since no activity. If you still need help, please feel free to reply with an update to this discussion, or create another discussion.

Thanks,

Yixing

0 Kudos

3,374 Views
YixingKong
Senior Contributor IV

Chuck

It seems you got the issue resolved. If yes, we are going to close the discussion in 3 days. If you still need help, please feel free to reply with an update to this discussion.

Thanks,

Yixing

0 Kudos

3,374 Views
zhuhansimida
Contributor I

is that mean, imx6 cannot support EGL in Mesa ?

http://wiki.wandboard.org/index.php/Building_Qt5_using_yocto_on_Wandboard

would it affect QT5 using EGLFS in wandboard ?

0 Kudos

3,374 Views
app025
Contributor III

Not really sure, but as far as I understood, EGL support is not provided by Mesa, but directly from gpu-viv package.

Anyone could confirm this?

0 Kudos

3,374 Views
cetzweiler
Contributor II

The tutorial only tells me how to do a "repo init" and a "repo sync".

Can anyone tell me how to get a version prior to it being broken on Friday?

Thank you,

Chuck

0 Kudos

3,374 Views
jbd1986
Contributor III

Chuck,

As a work-around, I have performed 'git checkout ec8ae16e35fd7db6a5bb12412d50ab6f355b0f6e" in openembedded-core.  This is the git commit that took place right before the one that introduces the build error we are seeing.

You could also point to this revision in your manifest file.

0 Kudos

3,374 Views
cetzweiler
Contributor II

Justin,

Thank you for your info.

I modified my file .repo/manifest.xml

I changed:

revision="dora"
to:
revision="ec8ae16e35fd7db6a5bb12412d50ab6f355b0f6e"


Then I did "repo sync".

I still get the same error.

Did I do this wrong?

Thank you for your help.


Chuck

0 Kudos

3,374 Views
jbd1986
Contributor III

Chuck, I believe repo sync actually pulls your manifest.xml file that you specify in the repo init command.  You would need to point repo init to your modified manifest.xml, meaning you have to commit and push those changes.  This would probably (but not definitely) require you to issue the repo init command a second time.  If you committed your manifest change directly to the branch you are currently testing, then you wouldn't need to repo init again, but I doubt you will want to commit this workaround to your stable branch.

So:

1) make manifest.xml changes

2) commit/push the changes to a branch

3) repo init with the new manifest.xml

4) repo sync

5) build

Alternatively (and the lazier, easier to test solution): after the repo sync, you should be able to go to the 'sources' directory and do the 'git checkout ec8ae16e35fd7db6a5bb12412d50ab6f355b0f6e'.  In my example above, that would be:

$ cd buildFolderName

$ repo sync

$ cd sources/openembedded-core

$ git checkout ec8ae16e35fd7db6a5bb12412d50ab6f355b0f6e

$ <do the building>

NOTE: I believe 'repo sync' is designed to take you to the clean and current revisions of whatever is in the manifest.xml that you passed to 'repo init'.  If you start making changes in your source directory, 'repo sync' will be unable to update those dirty source directories until you make them clean again.  I am a big fan of performing 'git stash' on those dirty directories before i repo sync.  This removes your changes, but allows them to be returned at a later date!

example:

$ cd buildFolderName

$ repo sync

<oh no, repo sync had an openembedded-core update error>

$ cd sources/openembedded-core

$ git stash

$ cd ../..

$ repo sync

<yay it worked!>

$ cd sources/openembedded-core

<I want those changes back>

$ git stash pop

I hope this helps!

Justin D.

0 Kudos

3,374 Views
jbd1986
Contributor III

Ah, you can also repo init on a local manifest.xml file.  See here: android - using a local_manifest.xml with repo - Stack Overflow

0 Kudos

3,374 Views
cetzweiler
Contributor II

I really appreciate your efforts.

None of this is working for me.

I don't have a sources/openembedded-core directory.

I have a sources/meta-openembedded directory.

If I add the line to my manifest file:

<project remote="oe" revision="ec8ae16e35fd7db6a5bb12412d50ab6f355b0f6e" name="meta-openembedded" path="sources/meta-openembedded"/>

I get:

GitError: meta-openembedded update-ref: fatal: ec8ae16e35fd7db6a5bb12412d50ab6f355b0f6e^0: not a valid SHA1

when I do "repo sync".

If I go into the meta-openembedded directory and "git checkout ec8ae16e35fd7db6a5bb12412d50ab6f355b0f6e", I get:

fatal: reference is not a tree: ec8ae16e35fd7db6a5bb12412d50ab6f355b0f6e

Can you  show me how to get the revision number for the meta-openembedded from last Thursday, I have a feeling that ec8ae16e35fd7db6a5bb12412d50ab6f355b0f6e is wrong for my project?

0 Kudos

3,374 Views
yatsze
Contributor I

None working for me as well.

0 Kudos

3,374 Views
jbd1986
Contributor III

I'm having the same issue, hopefully this gets resolved.

I did not see a corresponding patch in meta-fsl-arm/recipes-graphics in the dora branch to go along with this patch in oe-core: https://github.com/openembedded/oe-core/commit/4c6340dba65185acef7301762270fa1dc7e0afda

This issue is very likely related to that patch, since my build broke late Friday afternoon.  I also just found this post from otavio: http://www.mail-archive.com/meta-freescale@yoctoproject.org/msg07903.html