• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 102 subscribers
  • Views 464 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SK-AM62P-LP: Failed to build the SDK with Yocto in offline environment

jie.li.lij
Prodigy 60 points
Part Number: SK-AM62P-LP

Hi,

  I'm trying to build Processor SDK for AM62Px, I'm on an offline host machine

  • I'm preparing the local mirror (downloads folder) beforehand
  • I started to build with "BB_NO_NETWORK = 1"
  • Everything goes well except for one recipe
  • It seems that the recipe named "websocketd" was trying to get something from internet in the do_compile process.
  • Is there a way to prepare all the things it needed and build completely offline?

DEBUG: Executing shell function do_compile
go: github.com/gorilla/websocket@v1.4.0: Get "https://proxy.golang.org/github.com/gorilla/websocket/@v/v1.4.0.mod": dial tcp 216.58.203.81:443: i/o timeout
go: downloading github.com/gorilla/websocket v1.4.0
go: github.com/gorilla/websocket@v1.4.0: Get "https://proxy.golang.org/github.com/gorilla/websocket/@v/v1.4.0.mod": dial tcp 216.58.203.81:443: i/o timeout
go: github.com/gorilla/websocket@v1.4.0: Get "https://proxy.golang.org/github.com/gorilla/websocket/@v/v1.4.0.mod": dial tcp 216.58.203.81:443: i/o timeout
go: downloading github.com/gorilla/websocket v1.4.0
go: github.com/gorilla/websocket@v1.4.0: Get "https://proxy.golang.org/github.com/gorilla/websocket/@v/v1.4.0.mod": dial tcp 216.58.203.81:443: i/o timeout

  • 0
    TI__Guru 62557 points
    jie.li.lij said:
    It seems that the recipe named "websocketd" was trying to get something from internet in the do_compile process.

    This behavior is usually very much frowned upon in the Yocto community, and if such things are found they are usually fixed. One should be able to do a complete build only based on cached download files. It looks like this recipe is part of the TI additions, so let me file an internal issue report to have that build process updated and improved.

    For now, can you just remove the package (and its dependencies) from your build? Looks like in addition to removing websocketd from packagegroup-arago-base.bbappend you'll need to remove statcol from packagegroup-arago-tisdk-addons.bb. You should be able to do that either through local.conf or in your own layer.

    Regards, Andreas

    (ref: SITSW-3635)

  • 0 in reply to Andreas Dannenberg
    Prodigy 60 points

    Thank you ! I'll try it.

    And is it common for a recipe to request internet after the do_fetch stage? If this recipe is what we need, we can't just remove it, but change its behaviour to do the internet things in the do_fetch stage, right?

  • 0 in reply to jie.li.lij
    TI__Guru 62557 points
    jie.li.lij said:
    And is it common for a recipe to request internet after the do_fetch stage?

    No, recipes should not do that. It is considered bad practice. Everything needed for the build should get fetched at the 'fetch' stage.

    jie.li.lij said:
    but change its behaviour to do the internet things in the do_fetch stage, right?

    Yes. But depending on the recipe it may not be "easy" to fix, as it may involve modifying the sources/makefile(s) etc. of the associated project itself to look in certain folders for downloaded artifacts rather than trying to download them on the fly during build.

    If you do need those recipes and can't remove them, let us know, we can probably help figure out what needs to be done.

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Prodigy 60 points

    I can successfully build the tisdk-base-image after removing the websocketd dependency in my own layer, I'll try full-image build these days, it will be very helpful if you can guide me to modify the make process of upstream projects that also have this issue.

    Thank you in advance!

  • +1 in reply to jie.li.lij
    TI__Guru 62557 points
    jie.li.lij said:
    I can successfully build the tisdk-base-image after removing the websocketd dependency in my own layer

    I'm glad the basic build is working now.

    jie.li.lij said:
    it will be very helpful if you can guide me to modify the make process of upstream projects that also have this issue.

    I spent some more time on this, and it looks like there are other (non-TI) Yocto recipes like `influxdb` that have a similar issue but there isn't a readily available solution available at the moment to model after, at least I didn't see any. So I went ahead and filed an TI-internal issue report/enhancement request (SITSW-3657) to have this investigated by our software team and fixed for a future SDK, but I don't have a ready-to-go solution at this point. However doing a little further research it looks like it'll be along the lines of this post here: https://stackoverflow.com/a/65356780

    Also there's a way you can still do offline builds even with the recipe as it is, which is by leveraging Yocto's shared-state cache feature. If you build websocketd once (a specific version, that is), all build/binary artifacts are stored in the shared state cache, and the next time you do a full system build, assuming the shared state cache is accessible, Bitbake should just pull out the previously-built binary artifacts from the cache and use those to populate rootfs, etc. Here's some good discussion round this: https://bootlin.com/blog/yocto-sharing-the-sstate-cache-and-download-directories/

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Prodigy 60 points

    Thanks for adding this to TI's internal issue lists, I can imagine it's difficult to fix for every specific upstream project that may have a completely different build process.
    The bootlin tutorial is also very helpful !