Support for the ARM 64 bit CPU architecture (aarch64) was introduced in autoconf 2.69. scummvm appears to use an earlier version of autoconf, preventing its being built. This can be fixed in of three ways (In order of preference): 1. Work with upstream to migrate the package to autoconf 2.69. 2. Rerun autoconf or autoreconf in %prep or %build prior to running configure. 3. Apply the patch at http://ausil.fedorapeople.org/aarch64/scummvm/scummvm-aarch64.patch which updates config.guess and config.sub to recognize aarch64.
Thank you for your bug report. I don't know how to test whether a patched package would compile on aarch64. I haven't found any information how to do scratch-builds for this architecture. The information on https://fedoraproject.org/wiki/Architectures/AArch64 does not cover this. Scummvm does uses a manually written configure script (and the proposed patch is not available any more). Applying (and probably updating) an Fedora-specific patch would be cumbersome. Please understand, that in this case there is just not enough time to take care of non-primary architectures. In order to move forward I'd like to encourage you to directly work with upstream to get a patch applied. http://sourceforge.net/p/scummvm/bugs/ Once aarch64 is promoted to a primary Fedora architecture or the necessary build infrastructure (koji etc.) is in place / documented, please re-open the bug report and provide an updated patch. In this case, I'd happy to help to apply it for aarch64. In the meantime, I close the bug report as "UPSTREAM".
> I don't know how to test whether a patched package would compile on aarch64. > I haven't found any information how to do scratch-builds for this > architecture. like any of the secondary architectures: <arch>-koji build --scratch <release> blah.src.rpm > Scummvm does uses a manually written configure script (and the proposed > patch is not available any more). Applying (and probably updating) an > Fedora-specific patch would be cumbersome. Or the maintainer could submit it upstream for easy maintenance going forward > Please understand, that in this case there is just not enough time to take > care of non-primary architectures. Not asking you to take care of non primary architectures, asking you just to maintain the package > In order to move forward I'd like to encourage you to directly work with > upstream to get a patch applied. You should be doing this as the package maintainer. Architecture maintainers can assist. > Once aarch64 is promoted to a primary Fedora architecture or the necessary > build infrastructure (koji etc.) is in place / documented, please re-open > the bug report and provide an updated patch. In this case, I'd happy to help > to apply it for aarch64. The necessary koji secondary infra has been in place for some time: http://arm.koji.fedoraproject.org/ > In the meantime, I close the bug report as "UPSTREAM". That's not the correct resolution unless you reference associated bug that goes with it
Peter, Dennis, since the original patch is not available anymore, I just tried to build it without any additional changes. arm-koji build --scratch rawhide scummvm-1.7.0-1.fc22.src.rpm http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2787577 There are two issues: 1. libjpeg doesn't seem to be found correctly: Checking for libjpeg >= v6b... no Although the same version was installed as in F20 x86_64: DEBUG util.py:282: libjpeg-turbo aarch64 1.3.1-4.fc21 build 124 k Any idea? 2. So far it looks like that all sources can be compiled, but it fails at final linking: http://arm.koji.fedoraproject.org//work/tasks/7577/2787577/build.log Do you see any obvious problem? One additional question: In order to do the debugging by myself, is it possible to do local mock builds (cross-compilation) for aarch64? The naive approach doesn't work: mock -r fedora-rawhide-aarch64 scummvm-1.7.0-1.fc22.src.rpm ERROR: Cannot build target aarch64 on arch x86_64 What other option do I have to debug such problems above?
Peter, Dennis: *ping* - Please can you have a look at comment #3? Any help is highly appreciated.
http://arm.koji.fedoraproject.org//work/tasks/8814/2838814/build.log > 1. libjpeg doesn't seem to be found correctly: > > Checking for libjpeg >= v6b... no > > Although the same version was installed as in F20 x86_64: > > DEBUG util.py:282: libjpeg-turbo aarch64 1.3.1-4.fc21 build 124 k > > Any idea? Seems to find it OK: Checking for libjpeg >= v6b... yes > 2. So far it looks like that all sources can be compiled, but it fails at > final linking: > > http://arm.koji.fedoraproject.org//work/tasks/7577/2787577/build.log > > Do you see any obvious problem No, but it looks like it's similar to this issue: http://forums.scummvm.org/viewtopic.php?p=80783&sid=1f7b4fff3601f393e8e9d51bb5940316 > One additional question: > > In order to do the debugging by myself, is it possible to do local mock > builds (cross-compilation) for aarch64? The naive approach doesn't work: > > mock -r fedora-rawhide-aarch64 scummvm-1.7.0-1.fc22.src.rpm > ERROR: Cannot build target aarch64 on arch x86_64 > > What other option do I have to debug such problems above? Run a aarch64 VM using qemu on x86_64 https://fedoraproject.org/wiki/Architectures/AArch64/Install_with_QEMU
Fixed in rawhide. https://pkgs.fedoraproject.org/cgit/scummvm.git/commit/?id=246cc5c4e435d8340320b3d953339e1103fbef9a successful scratch-build: https://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2841260