Description of problem: To be honest, I'm not sure if I should fill this against qemu or cmake, but apparently this problem only appears under qemu-arm (from qemu-user package), hence qemu for now. The problem I found is that "file(GLOB ...)" command under qemu-arm doesn't work properly: it never finds anything. A simple cmake script to exhibit the behavior follows: sample.cmake: file(GLOB test /*) message("Found: ${test}") Running it normally using "cmake -P sample.cmake" outputs dirs/files in /: $ cmake -P sample.cmake Found: /@System.solv;/bin;/boot;/dev;/etc;/home;/lib;/lib64;/lost+found;/media;/mnt;/opt;/proc;/root;/run;/sbin;/srv;/sys;/tmp;/usr;/var However, running the same command under qemu-arm returns nothing: $ cmake -P sample.cmake Found: Version-Release number of selected component (if applicable): qemu-user-4.1.1-1.fc31.x86_64 How reproducible: 100%
Thanks for the report. Can you see if this reproduces with a newer qemu from the virt-preview repo? https://copr.fedorainfracloud.org/coprs/g/virtmaint-sig/virt-preview/ If it still reproduces, please file your bug in the upstream qemu tracker, these types of issues often get fixed quickly with upstream reports https://www.qemu.org/contribute/report-a-bug/
Recompiling cmake with -D_FILE_OFFSET_BITS=64 fixes the issue. Ref.: https://gitlab.kitware.com/cmake/cmake/-/issues/20568
So it seems that it should be fixed in Fedora cmake packages for arm 32bit.
Apparently this is fixed upstream in this MR: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5258/diffs
Can you confirm which version of cmake you're testing?
Nevermind, git to the rescue: $ git tag --contains 5b10f96793ab6f3a4ef446d67c09ea91b7898584 contains v3.19.0 v3.19.0-rc1 v3.19.0-rc2 v3.19.0-rc3 v3.19.1 v3.19.2 v3.19.3 v3.19.4 v3.19.5 v3.19.6 v3.20.0-rc1 v3.20.0-rc2 v3.20.0-rc3 v3.20.0-rc4 So, looks like it was only fixed in cmake-3.19.0 and newer (f33-updates latest is still on 3.18). I'm surprised this issue hasn't broken builds in any noticable way yet (or it may have gone unnoticed) :( Anyway, update on the way.
FEDORA-2021-8e5e7f7775 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-8e5e7f7775
Thanks for the fast update, it fixes this problem. :)
FEDORA-2021-8e5e7f7775 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-8e5e7f7775` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-8e5e7f7775 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-8e5e7f7775 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.