• State Suggested Answer
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 65 subscribers
  • Views 1901 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 291537
Options

Project cannot be built in a docker container

balix

Hello,

I need to build a project in a Docker container. It built fine under Windows 10 with a connect SDK v1.9.1.

Now I am using a Docker image built with the Dockerfile for nrfconnect-toolchain: https://github.com/NordicPlayground/nrfconnect-chip-docker/tree/master/nrfconnect-toolchain

1. I am not sure which version of the connect SDK is installed with this image but I assume it would be the latest one (v2.0.0). Would that be incompatible with my project which was built with a SDK v1.9.1?

2. My main issue is an error during the build with west that I don't understand:

root@a81dfea4756f:/workspace/nRF52840_zephyr-bsp# west build
-- west build: generating a build system
Loading Zephyr default modules (Zephyr base (cached)).
-- Application: /workspace/nRF52840_zephyr-bsp
-- Cache files will be written to: /workspace/nRF52840_zephyr-bsp/zephyr/.cache
-- Zephyr version: 3.1.99 (/workspace/nRF52840_zephyr-bsp/zephyr)
-- Found west (found suitable version "0.13.1", minimum required is "0.7.1")
-- Board: nrf52840dk_nrf52840
-- Found dtc: /usr/bin/dtc (found suitable version "1.6.0", minimum required is "1.4.6")
-- Found toolchain: gnuarmemb (/opt/gcc-arm-none-eabi-9-2019-q4-major)
-- Found BOARD.dts: /workspace/nRF52840_zephyr-bsp/zephyr/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840.dts
-- Generated zephyr.dts: /workspace/nRF52840_zephyr-bsp/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: /workspace/nRF52840_zephyr-bsp/build/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: /workspace/nRF52840_zephyr-bsp/build/zephyr/include/generated/device_extern.h
-- Including generated dts.cmake file: /workspace/nRF52840_zephyr-bsp/build/zephyr/dts.cmake

/workspace/nRF52840_zephyr-bsp/prj.conf:28: warning: attempt to assign the value 'y' to the undefined symbol BT_LL_SOFTDEVICE

/workspace/nRF52840_zephyr-bsp/prj.conf:31: warning: attempt to assign the value 'y' to the undefined symbol BT_GATT_DM

/workspace/nRF52840_zephyr-bsp/prj.conf:33: warning: attempt to assign the value 'y' to the undefined symbol BT_RECV_IS_RX_THREAD
Parsing /workspace/nRF52840_zephyr-bsp/Kconfig
Loaded configuration '/workspace/nRF52840_zephyr-bsp/zephyr/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840_defconfig'
Merged configuration '/workspace/nRF52840_zephyr-bsp/prj.conf'

error: Aborting due to Kconfig warnings

CMake Error at zephyr/cmake/modules/kconfig.cmake:290 (message):
  command failed with return code: 1
Call Stack (most recent call first):
  zephyr/cmake/modules/zephyr_default.cmake:121 (include)
  zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:66 (include)
  zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:96 (include_boilerplate)
  CMakeLists.txt:11 (find_package)


-- Configuring incomplete, errors occurred!
FATAL ERROR: command exited with status 1: /usr/local/bin/cmake -DWEST_PYTHON=/usr/bin/python3 -B/workspace/nRF52840_zephyr-bsp/build -S/workspace/nRF52840_zephyr-bsp -GNinja

I saw this ticket which seems to talk about what appears to be a related issue:  Cannot Replicate Build in Docker Environment

However the workaround addressed in this ticket did not work in my case.

Regards,

Benjamin

  • 0

    Hello Benjamin,

    Your Devzone post regarding Docker build errors, specifically Kconfig symbols which the build process finds not defined catches my eye.  While working on an out-of-tree driver for an unsupported sensor, I encountered this same type of error a few months ago early on.  I write because I wonder whether your situation is not a problem with Docker container, but rather something may be missing in your project's included Kconfig files.

    While I'm not using any Bluetooth features yet, I text searched from the root of my ncs version 1.6.1 workspace for the symbols your build output shows not defined.  BT_LL_SOFTDEVICE appears in these files in my local copy of Nordic's nrf SDK:

    ted@localhost:~/projects/zephyr-based$ grep -nr BT_LL_SOFTDEVICE ./* | grep -v CONFIG_ | grep BT_LL_SOFTDEVICE
./nrf/applications/nrf_desktop/src/modules/Kconfig.ble:212:	depends on BT_LL_SOFTDEVICE
./nrf/applications/nrf_desktop/src/modules/Kconfig.ble:238:	depends on BT_LL_SOFTDEVICE
./nrf/tests/drivers/nrfx_integration_test/Kconfig:86:config NRFX_AND_BT_LL_SOFTDEVICE
./nrf/tests/drivers/nrfx_integration_test/Kconfig:95:	default BT_LL_SOFTDEVICE if NRFX_AND_BT_LL_SOFTDEVICE
./nrf/subsys/mpsl/Kconfig:12:	default SDC_RX_PRIO if BT_LL_SOFTDEVICE
./nrf/subsys/caf/modules/Kconfig.ble_state:11:	select BT_CTLR_TX_PWR_DYNAMIC_CONTROL if BT_LL_SOFTDEVICE
./nrf/subsys/caf/modules/Kconfig.ble_state:30:	depends on BT_LL_SOFTDEVICE
./nrf/subsys/bluetooth/controller/Kconfig:15:	default 1536 if BT_LL_SOFTDEVICE
./nrf/subsys/bluetooth/controller/Kconfig:44:	default 2048 if BT_LL_SOFTDEVICE
./nrf/subsys/bluetooth/Kconfig:12:# BT_LL_SOFTDEVICE which is tested with 20 connections.
./nrf/subsys/bluetooth/Kconfig:16:	range 2 20 if BT_LL_SOFTDEVICE && BT_CENTRAL && BT_PERIPHERAL
./nrf/subsys/bluetooth/Kconfig:17:	range 1 20 if BT_LL_SOFTDEVICE
./nrf/subsys/bluetooth/Kconfig:18:	default 2 if BT_LL_SOFTDEVICE && BT_CENTRAL && BT_PERIPHERAL
./nrf/subsys/bluetooth/Kconfig:20:if BT_LL_SOFTDEVICE
./nrfxlib/softdevice_controller/Kconfig:13:config BT_LL_SOFTDEVICE_VS_INCLUDE
./nrfxlib/softdevice_controller/Kconfig:18:config BT_LL_SOFTDEVICE_DEFAULT
./nrfxlib/softdevice_controller/Kconfig:19:	bool "Select BT_LL_SOFTDEVICE as default BT_LL_CHOICE"
./nrfxlib/softdevice_controller/Kconfig:36:	default BT_LL_SOFTDEVICE
./nrfxlib/softdevice_controller/Kconfig:38:config BT_LL_SOFTDEVICE
./nrfxlib/softdevice_controller/Kconfig:63:if BT_LL_SOFTDEVICE
./nrfxlib/softdevice_controller/Kconfig:104:endif # BT_LL_SOFTDEVICE

    The last file in these results is of particular interest to me, because it contains the stanza `./nrfxlib/softdevice_controller/Kconfig:38:config BT_LL_SOFTDEVICE`.  When I faced the same "symbol not defined" errors in my out-of-tree driver work, this is the line I was missing in the most nested Kconfig file of my small driver directory and Kconfig hierarchy.

    I did similar searches for the other two symbols with similar results:

    ted@localhost:~/projects/zephyr-based$ grep -nr BT_GATT_DM ./* | grep -v CONFIG_ | grep BT_GATT_DM
./nrf/include/bluetooth/gatt_dm.h:7:#ifndef BT_GATT_DM_H_
./nrf/include/bluetooth/gatt_dm.h:8:#define BT_GATT_DM_H_
./nrf/include/bluetooth/gatt_dm.h:338:#endif /* BT_GATT_DM_H_ */
./nrf/subsys/bluetooth/Kconfig.discovery:7:menuconfig BT_GATT_DM
./nrf/subsys/bluetooth/Kconfig.discovery:12:if BT_GATT_DM
./nrf/subsys/bluetooth/Kconfig.discovery:14:config BT_GATT_DM_MAX_ATTRS
./nrf/subsys/bluetooth/Kconfig.discovery:20:config BT_GATT_DM_DATA_PRINT
./nrf/subsys/bluetooth/Kconfig.discovery:26:module = BT_GATT_DM
./nrf/subsys/bluetooth/Kconfig.discovery:30:endif # BT_GATT_DM
./nrf/subsys/bluetooth/services/Kconfig.latency_c:10:	select BT_GATT_DM

ted@localhost:~/projects/zephyr-based$ grep -nr BT_RECV_IS_RX_THREAD ./* | grep -v CONFIG_ | grep BT_RECV_IS_RX_THREAD
./nrf/subsys/bluetooth/controller/Kconfig:23:	depends on BT_HCI_HOST || BT_RECV_IS_RX_THREAD
./zephyr/drivers/bluetooth/hci/Kconfig:18:	select BT_RECV_IS_RX_THREAD
./zephyr/subsys/bluetooth/controller/Kconfig:98:	select BT_RECV_IS_RX_THREAD
./zephyr/subsys/bluetooth/host/Kconfig:73:config BT_RECV_IS_RX_THREAD
./zephyr/subsys/bluetooth/host/Kconfig:85:	depends on BT_HCI_HOST || BT_RECV_IS_RX_THREAD
./zephyr/subsys/bluetooth/host/Kconfig:101:	depends on BT_HCI_HOST || BT_RECV_IS_RX_THREAD
./zephyr/subsys/bluetooth/common/Kconfig:98:	default 3 if BT_RECV_IS_RX_THREAD
./zephyr/subsys/bluetooth/common/Kconfig:129:	default 3 if BT_RECV_IS_RX_THREAD

    Symbol BT_GATT_DM has a `menuconfig` type declaration, so that is a little different than the key line I needed (confirmed by Jared Wolff at https://community.circuitdojo.com) but I find these symbols are part of my west workspace.

    Are you able to locate these same or comparable Kconfig files under the root of your project in Docker?  If they are present there the question then becomes whether or why the build process is not seeing them included some time soon after the first Kconfig file is processed.

    So I am wondering now what tool we have which can more verbosely show us how Kconfig files are included at build time?  After creating your Docker instance, did you both git clone your project(s) and invoke `west init` on them?  While not directly related to Kconfig processing, I know that `west init` has a major impact on where different west-guided elements of the build process look for project dependencies.

    I will keep an eye on your Devzone ticket 89477 as I am myself trying to move our team's Zephyr based firmware into a Docker image.  Either way I hope this can help you some, Benjamin.

    - Ted

  • 0 in reply to tedhavelka

    Hi Ted,

    I tried to build my project without a Docker container. So what I did is follow the manual installation guide on a WSL: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/gs_installing.html

    And then I faced the exact same error in this environment, so it appears that you are right and my issue is not related to the Docker container I used.

    Now I am a bit confused because if I understand correctly your ncs folder is at the same place than your project?

    The guide does not specify where it should be installed so I created the ncs folder in my home directory.

    And then your grep commands return nothing if I run them inside my project folder but I got the same result as you if I run it in my ncs folder.

    Should these files (ncs) be in my project instead?

    Benjamin

  • 0 in reply to balix

    Hello Benjamin, 

    The DevZone team is currently entering summer vacation period, some delay in answers must be expected.


    From the log output I see that your compiler is using Zephyr version: 3.1.99 (/workspace/nRF52840_zephyr-bsp/zephyr). Please note that nRF Connect SDK v2.0.0 integrates v3.0.99, and nRF Connect SDK v1.9.1 integrates v2.7.99.

    This is most likely the reason for why it will fail. Regarding the details of the docker image itself I will need more time.

    Kind regards,
    Øyvind

  • 0 in reply to Øyvind

    Thanks for the info Øyvind.

    As a matter of fact I managed to solve the issue and it seems to be indeed an issue with the toolchain and sdk version used.

    I cleaned the repository containing the project in order to start fresh in the WSL environment.

    Then I did the following:

    cd nRF52840_zephyr-bsp/

    west init -m https://github.com/nrfconnect/sdk-nrf --mr v1.9.1

    west update

    west build -b nrf52840dk_nrf52840

    Before that I was just using west init alone at the root of the project assuming that it would use the nrf-sdk I installed in my  home directory. Or maybe it should have been the case? Maybe I did something wrong following the installation guide?

  • 0 in reply to balix

    Hello Benjamin, 

    balix said:
    Before that I was just using west init alone at the root of the project assuming that it would use the nrf-sdk I installed in my  home directory.

    After doing west init, you must run west update to clone the project repositories. 

    balix said:
    Maybe I did something wrong following the installation guide?

    Based on the above, I think that is the answer to your question Slight smile

    Kind regards,
    Øyvind

Related

core_v2_widget.Hide()