Picture file 'STM32F429I-Discovery.jpg' not found.

[wolfrz]

In MacOS, execute the following command: qemu-system-gnuarmeclipse -d unimp,guest_errors -board STM32F429I-Discovery -image build/*.elf The error message is "Picture file 'stm32f429i-discovery.jpg' not found."

But I executed the following command and succeeded: ~/Library/xPacks/qemu-arm/2.8.0-8/bin/qemu-system-gnuarmeclipse -d unimp,guest_errors -board STM32F429I-Discovery -image build/*.elf

I don't know what caused this. Does anyone know how to solve this problem?

[ilg-ul]

Thank you for reporting, it looks like a bug.

The jpg is loaded from a folder with a path relative to the executable, and when you start it without any path, it gets confused.

The workaround is to always start it with a path.

[ilg-ul]

I added the following patch to fix the issue:

https://github.com/xpack-dev-tools/qemu/commit/fd116bd1e91eef7af73d61a388e2f8c2152cbdac

Please test the following binary on your macOS machine and let me know if the problem was fixed:

https://github.com/xpack-dev-tools/pre-releases/releases/download/test/xpack-qemu-arm-2.8.0-9-darwin-x64.tar.gz

The curious thing is that although the problem is obvious, somehow in my environment the same test (starting the executable without a path) worked, so I could not reproduce the problem. But I remember in the past I encountered this behaviour, so it is real.

For those interested in details, when a program is started with a full path, it is obvious how to determine the base folder and from it compute the location of the other program data, like pictures.

When the program is started without a path, things get more complicated, and the solution is platform dependent. The macOS case was missing, and fallback mechanisms were used, sometimes with unreliable results. The correct macOS function for returning the executable path was identified and used.

[ilg-ul]

@wolfrz ?

[wolfrz]

Thank you!

[ilg-ul]

Is it ok now on your system?

[wolfrz]

Yes, it works on my MacOS.

[ilg-ul]

Fixed on 2020-03-29.