Skip to content

[BUG] IMX: Topology build fails after recent change #9997

Closed
Closed
[BUG] IMX: Topology build fails after recent change#9997
Assignees
dbalutalgirdwood
Labels
P2Critical bugs or normal featuresbugSomething isn't working as expected

Description

@dbaluta
dbaluta
opened on May 9, 2025

Describe the bug

Building topology now fails after commit 47dd8d3

Our environment adds the alsatplg using the PATH but the commit mentioned above uses an explicit alsatplg. This breaks the build.

To Reproduce

./scripts/build-tools.sh

Reproduction Rate

100%

Expected behavior

build shouldn't break

Impact
Building SOF binaries fails.

Environment

  1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).

    • Kernel: doesnt matter
    • SOF: 137c9be

  2. Name of the topology file

    • Topology: topology doesnt build

  3. Name of the platform(s) on which the bug is observed.

    • Platform: imx8m

Activity

  1. dbaluta
    added
    bugSomething isn't working as expected
    on May 9, 2025

  2. dbaluta commented on May 9, 2025

    @dbaluta
    dbaluta
    on May 9, 2025
    CollaboratorAuthor

    @lgirdwood can you add the alsatplg in the PATH variable? Is it OK to revert this change?

  3. lgirdwood commented on May 9, 2025

    @lgirdwood
    lgirdwood
    on May 9, 2025
    Member

    @lgirdwood can you add the alsatplg in the PATH variable? Is it OK to revert this change?

    @dbaluta do you mean adding the local ALSA binaries to the users $PATH ? This could conflict with system ALSA/audio. Can you share the error you are seeing. Running the script should build all topologies.

  4. abonislawski
    assigned
    dbaluta
    and
    lgirdwood
    on May 13, 2025
  5. abonislawski
    added
    P2Critical bugs or normal features
    on May 13, 2025

  6. dbaluta commented on May 13, 2025

    @dbaluta
    dbaluta
    on May 13, 2025
    CollaboratorAuthor
      /home/bamboo/sof_dir/sof/tools/../../tools/bin/alsatplg --version returned
  status: No such file or directory,
Call Stack (most recent call first):
  topology/CMakeLists.txt:34 (alsatplg_version)
  CMake Warning at topology/CMakeLists.txt:36 (message):
  /home/bamboo/sof_dir/sof/tools/../../tools/bin/alsatplg failed: No such file or directory; all topologies skipped

    And it expected because SOF scripts expect the alsatplg to be installed in a custom directory /home/bamboo/sof_dir/sof/tools/../../tools/bin/alsatplg but on our machine the alsatplg local compiled version is installed in a different directory.

    My concern here is that we force the users to install the ALSA tool in a hardcoded location instead of a flexible location.

    We quickly fixed this by creating a link from /home/bamboo/sof_dir/sof/tools/../../tools/bin/alsatplg to where our alsatplg is installed.

    I don't have a strong opinion on this, but I would like to have an option to use a different location OR at least use the system alsatplg. We the current implementation is no longer possible, user is forced to install the alsa tools in a exact location, otherwise the build will fail.

  7. kv2019i commented on May 13, 2025

    @kv2019i
    kv2019i
    on May 13, 2025
    Collaborator

    @dbaluta We discussed these concerns in #9870 review and e.g. about the location in #9870 (comment) . SOF_WORKSPACE (I admit, I didn't realize we had this in our original public docs) can be used to change adjust the install location, but there's no option to use system tplg.

  8. kv2019i commented on May 16, 2025

    @kv2019i
    kv2019i
    on May 16, 2025
    Collaborator

    @dbaluta Any takes how we want to proceed? I'd need to backport Liam's PR to stable-v2.2 to unblock the CI, but yeah, do we stick this approach on main.

    Mandating local ALSA installs does have the nice property that we can introduce topology features changes in SOF pull-requests, adding the alsa-lib/utils changes at the same time as the changes to topologies, and have them tested at same time. Now we frequently have issues with people using old alsa-lib/utils (either omission or mistake in tool install), resulting in buggy topologies binaries.

  9. lgirdwood commented on May 16, 2025

    @lgirdwood
    lgirdwood
    on May 16, 2025
    Member

    I don't have a strong opinion on this, but I would like to have an option to use a different location OR at least use the system alsatplg. We the current implementation is no longer possible, user is forced to install the alsa tools in a exact location, otherwise the build will fail.

    @dbaluta So I guess this also is needed by Yocto? as it 's ALSA recipe is probably very much more bleeding edge than say Fedora or Ubuntu (which is why building with system ALSA does not work). No objections though if a command line arg is needed to override ALSA $PATH

  10. dbaluta commented on May 16, 2025

    @dbaluta
    dbaluta
    on May 16, 2025
    CollaboratorAuthor

    @kv2019i @lgirdwood we fixed this internally in Yocto for now, we can close this and will come back maybe with an improvement if necessary later.

  11. dbaluta
    closed this as completedon May 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P2Critical bugs or normal featuresbugSomething isn't working as expected

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions