host-zstd has derived objects outside designated build dir

[udance4ever]

for some reason there is something unique abouthost-zstd that causes pbuilder to direct buildroot to put derived objects of this pkg (only) in the rootbuild directory instead of build/host-zstd-1.5.5 (directory got created but it’s empty). All other pkgs have their files in their subdirectories.

this is low priority as its not a showstopper - the package gets built and installed and just want to make a note of it.

log file:
host-zstd.log.gz

[udance4ever]

I’m just noticing this buildroot warning which might have something to do with it:

WARNING: unmet direct dependencies detected for BR2_PACKAGE_VKD3D_PROTON
  Depends on [n]: (BR2_i386 [=n] || BR2_x86_64 [=y]) && !BR2_STATIC_LIBS [=n] && BR2_PACKAGE_SPIRV_HEADERS [=y] && BR2_PACKAGE_DXVK [=y] && BR2_PACKAGE_HOST_ZSTD [=n]
  Selected by [y]:
  - BR2_PACKAGE_BATOCERA_WINE [=y]

I actually don’t understand the warning because the target is able to build successfully. That said, I’m guessing some kind of logic in pbuilder is thrown off because it ends up building host-zstd despite it not being selected.

@BryanForbes might you have some insight on this buildroot warning (above) as you were working on ironing out wine crossbuilds?

this must be some kind of edge case that doesn’t have to be dealt with if pbuilder can safely assume all buildroot dependency warnings have been resolved.

[paguilar]

The packages that br-pbuilder builds are taken from the dependencies generated by make -s --no-print-directory show-info and stored in the file .pbuilder.deps in buildroot's build directory. For example, the dependencies file generated after the configuration make O=$PWD/output/x86_64 BR2_EXTERNAL=$PWD -C $PWD/buildroot batocera-x86_64_defconfig shows that host-zstd is selected by the package cemu. May be the packages selection is not a direct br-pbuilder issue and in the test I'm running with the above configuration host-zstd is correctly installed inside build/host-zstd-1.5.5. In any case, I leave this issue open just to check if it happens again with this or some other package.

[udance4ever]

interesting - i went to check two pbuilds:

1. x86_64 - the build that had derrived objects in the parent directory that completed and was successful. the host-zstd-1.5.5 is no longer empty (but there is also clutter in the parent directory). I can only assume that it got built again because it the objects weren’t were they were supposed to be.
2. bcm2836 - I’m running a pbuild now and it has the objects in the correct directory

In the interests of reducing the number of open issues, I’m totally okay reopening this issue if it happens again!

[udance4ever]

just a heads up this issue appears to be reproducible. I just fired off a clean build of bcm2836 and host-zstd derived objects are in the top level build directory.

The extract took place in the correct directory:host-zstd-1.5.5

Just all the host-zstd derived objects are in the wrong directory.

[paguilar]

I confirm that I can reproduce it, although I'm not sure why it's happening specifically with this package.