varigit/meta-variscite-fslc

unable to execute 'x86_64-linux-gnu-gcc': No such file or directory

Closed this issue · 18 comments

oriolrius commented

I've got the error described in the title of the issue, I also include the log file take a look at the end of the issue. The binary is available in the system in /usr/bin. Maybe I missed any layer for compilation, this is my bblayer:

POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS = " \
  /home/yocto/poky/meta \
  /home/yocto/poky/meta-poky \
  \
  /home/yocto/poky/meta-openembedded/meta-oe \
  /home/yocto/poky/meta-openembedded/meta-multimedia \
  \
  /home/yocto/poky/meta-freescale \
  /home/yocto/poky/meta-freescale-3rdparty \
  /home/yocto/poky/meta-freescale-distro \
  \
  /home/yocto/poky/meta-browser \
  /home/yocto/poky/meta-openembedded/meta-gnome \
  /home/yocto/poky/meta-openembedded/meta-networking \
  /home/yocto/poky/meta-openembedded/meta-python \
  /home/yocto/poky/meta-qt5 \
  /home/yocto/poky/meta-swupdate \
  /home/yocto/poky/meta-variscite-fslc \
"

Error output:

log.zip

varigigi commented

Hi,
there's the chance that any of the previous building steps failed.
Please open a support ticket using our customer portal at
https://varisciteportal.axosoft.com/login
and add a full build log.
Thanks
BR
Pier

oriolrius commented
varigigi commented

Hi Oriol,
your account will be approved ASAP.
Thanks
BR
Pier

eranmati commented

The account is now approved.

johannesschrimpf commented

I got the same error and tracked it down to the environment variables in the python script lib/libfdt/setup.py. The problem is that x86_64-linux-gnu-gcc is in /usr/bin, which is not in PATH when the python script runs.

I added a patch with a work-around in my local setup which adds /usr/bin to the PATH variable in the python script. This solved the issue (at least the symptoms), but I guess the real error here is that setup.py deletes the CC variable (to ensure host build instead of cross compilation) and does not set the host CC properly, so it defaults to x86_64-linux-gnu-gcc which is outside the yocto environment.

As a proper solution, I suppose it's possible to set up use of the yocto host cc.

oriolrius commented
johannesschrimpf commented

Here is my work-around. Again, I don't think this is a proper solution, but it solved the building issue for me. I haven't tested the resulting image though. I suggest rather setting CC to the proper host c compiler which is present in the PATH variable.

u-boot-variscite.bbappend:

FILESEXTRAPATHS_prepend := "${THISDIR}:"
SRC_URI += "file://host_cc.patch"

host_cc.patch:

diff --git a/lib/libfdt/setup.py b/lib/libfdt/setup.py
index 62e7bcc1ac..8c0a26a2d0 100644
--- a/lib/libfdt/setup.py
+++ b/lib/libfdt/setup.py
@@ -11,6 +11,7 @@ import sys
 # Don't cross-compile - always use the host compiler.
 del os.environ['CROSS_COMPILE']
 del os.environ['CC']
+os.environ["PATH"] += ":/usr/bin"
 
 progname = sys.argv[0]
 cflags = sys.argv[1]
eranmati commented

Hi.
I've never seen this issue (and I've also just verified again now that there is no issue bitbaking U-Boot).
Did you use our variwiki.com website and follow all the steps in the following page?
http://variwiki.com/index.php?title=Yocto_Build_Release&release=RELEASE_SUMO_V1.0_DART-6UL

Regards,
Eran

johannesschrimpf commented

My rocko setup is stable, but I observed the issue several times in sumo.

eranmati commented

Can you provide instructions how to reproduce the issue?

By the way, instead of the patch above you can probably add x86_64-linux-gnu-gcc to HOSTTOOLS in Yocto (e.g. in conf/local.conf under your build directory, or in sources/meta-variscite-fslc/conf/layer.conf). However, this is still a workaround which shouldn't be needed as far as I can tell.

Regards,
Eran

oriolrius commented

@johannesschrimpf thank you very much, it works perfectly after adding your bbappend and patch files to a recipe.

Now I have a base image, could you tell how can I run this image with qemu for testing? thank you very much and so sorry for the offtopic.

Regards and thanks all
Oriol

oriolrius commented

Can you provide instructions how to reproduce the issue?

By the way, instead of the patch above you can probably add x86_64-linux-gnu-gcc to HOSTTOOLS in Yocto (e.g. in conf/local.conf under your build directory, or in sources/meta-variscite-fslc/conf/layer.conf). However, this is still a workaround which shouldn't be needed as far as I can tell.

Regards,
Eran

I don't use exactly what you say in the variwiki.com documentation, because I want to use a vanilla poky clone and then add the exact same layers with the same checkout signatures that you have in the official documentation. I don't feel comfortable using your poky package. IMHO the best way to proceed with an image is using the regular procedure no the ad-hoc approx that each manufacturer proposes for their board.

Maybe @johannesschrimpf approach is not the nicest way of solving the problem, but at least allows me to use a regular way of using Yocto with the regular tree structure.

BTW, thank you everyone, for your help.

eranmati commented

Our poky clone is also "vanilla".
We don't do anything special other than setting the layers and the specific commit id for each layer (which you said you used the same).

As I wrote, adding x86_64-linux-gnu-gcc to HOSTTOOLS will probably also solve your issue, without the need of a patch.

I'm closing this issue again, since you did not provide a way to reproduce it, and since you already have a solution anyway.

Next time please create a support ticket in our customer portal instead of posting your issues here.

Regards,
Eran

gizero commented

I got hit by this one as well with several build hosts setups. Looks like this was already tracked by Yocto people after u-boot v2017.03 and a patch is available upstream that solves the issue. I'd suggest merging #15 and keeping the patch around until next u-boot upgrade.

  • 👍1
eranmati commented

@gizero the upstream patch you are referring to allows using python from a location not in PATH.
I don't think it is related to this issue which is about x86_64-linux-gnu-gcc.
Anyway, I still can't reproduce any issue, neither with python nor with x86_64-linux-gnu-gcc.

gizero commented

I can't see the exact connection myself as well, but I suspect OE not being able to use it's own native Python instead of the host provided one is the trigger into a more subtle host contamination issue, which renders the issue not reproducible on most hosts. Moreover here I have a 1 to 1 scenario that's broken on sumo (both building on native Ubuntu and within a containerized environment). Having the patch mentioned above fixes all of them. Would be nice if @johannesschrimpf and @oriolrius could provide feedback on #15 in their failing setups.

johannesschrimpf commented

@gizero I tested with thud, and the patch indeed seems to fix the problem and libfdt compiles. I run into another problem in my thud setup, but this is not related to this issue.

eranmati commented

Ok, I see no reason not to commit this patch - patch committed.
Thanks.