Build error in u-boot-dm/master
Simon,
All 32-bit Tegra builds of u-boot-dm/master are failing with the following (this log is from Harmony):
CC spl/common/spl/spl.o CC spl/lib/display_options.o LD spl/common/spl/built-in.o LD spl/lib/built-in.o LD spl/u-boot-spl OBJCOPY spl/u-boot-spl-nodtb.bin COPY spl/u-boot-spl.bin BINMAN u-boot-tegra.bin binman: bad magic number in 'binman.etype': b'\x03\xf3\r\n' /var/lib/jenkins/workspace/u-boot-denx_uboot_dm-master-build/src/u-boot/Makefile:1619: recipe for target 'u-boot-tegra.bin' failed make[1]: *** [u-boot-tegra.bin] Error 1
Hi Stephen,
On Mon, 27 Apr 2020 at 10:04, Stephen Warren swarren@wwwdotorg.org wrote:
Simon,
All 32-bit Tegra builds of u-boot-dm/master are failing with the following (this log is from Harmony):
CC spl/common/spl/spl.o CC spl/lib/display_options.o LD spl/common/spl/built-in.o LD spl/lib/built-in.o LD spl/u-boot-spl OBJCOPY spl/u-boot-spl-nodtb.bin COPY spl/u-boot-spl.bin BINMAN u-boot-tegra.bin binman: bad magic number in 'binman.etype': b'\x03\xf3\r\n' /var/lib/jenkins/workspace/u-boot-denx_uboot_dm-master-build/src/u-boot/Makefile:1619: recipe for target 'u-boot-tegra.bin' failed make[1]: *** [u-boot-tegra.bin] Error 1
Oh wow, that is a strange one. Could it be bad Python cache files again?
Regards, Simon
On 4/27/20 11:02 AM, Simon Glass wrote:
Hi Stephen,
On Mon, 27 Apr 2020 at 10:04, Stephen Warren swarren@wwwdotorg.org wrote:
Simon,
All 32-bit Tegra builds of u-boot-dm/master are failing with the following (this log is from Harmony):
CC spl/common/spl/spl.o CC spl/lib/display_options.o LD spl/common/spl/built-in.o LD spl/lib/built-in.o LD spl/u-boot-spl OBJCOPY spl/u-boot-spl-nodtb.bin COPY spl/u-boot-spl.bin BINMAN u-boot-tegra.bin binman: bad magic number in 'binman.etype': b'\x03\xf3\r\n' /var/lib/jenkins/workspace/u-boot-denx_uboot_dm-master-build/src/u-boot/Makefile:1619: recipe for target 'u-boot-tegra.bin' failed make[1]: *** [u-boot-tegra.bin] Error 1
Oh wow, that is a strange one. Could it be bad Python cache files again?
Ah yes, so it is. I'd forgotten about that, and initially thought it couldn't be the issue, since the problem only affects some boards not all, and on my system they're all built in the same source tree (serially). However, I guess our 64-bit builds don't run the tool that triggers the problem, so that explains the differences.
Deleting tools/binman/etype/__init__.pyc did solve the issue, and that file doesn't get re-created if 16287933a8 "binman: Move to absolute imports" is applied.
Do you know what causes the issue, or how it can be avoided?
Maybe running "git clean -fdx" on the source tree before building would be a workaround, but I'd rather solve the root-cause if possible.
Hi Stephen,
On Mon, 27 Apr 2020 at 12:44, Stephen Warren swarren@wwwdotorg.org wrote:
On 4/27/20 11:02 AM, Simon Glass wrote:
Hi Stephen,
On Mon, 27 Apr 2020 at 10:04, Stephen Warren swarren@wwwdotorg.org wrote:
Simon,
All 32-bit Tegra builds of u-boot-dm/master are failing with the following (this log is from Harmony):
CC spl/common/spl/spl.o CC spl/lib/display_options.o LD spl/common/spl/built-in.o LD spl/lib/built-in.o LD spl/u-boot-spl OBJCOPY spl/u-boot-spl-nodtb.bin COPY spl/u-boot-spl.bin BINMAN u-boot-tegra.bin binman: bad magic number in 'binman.etype': b'\x03\xf3\r\n' /var/lib/jenkins/workspace/u-boot-denx_uboot_dm-master-build/src/u-boot/Makefile:1619: recipe for target 'u-boot-tegra.bin' failed make[1]: *** [u-boot-tegra.bin] Error 1
Oh wow, that is a strange one. Could it be bad Python cache files again?
Ah yes, so it is. I'd forgotten about that, and initially thought it couldn't be the issue, since the problem only affects some boards not all, and on my system they're all built in the same source tree (serially). However, I guess our 64-bit builds don't run the tool that triggers the problem, so that explains the differences.
Deleting tools/binman/etype/__init__.pyc did solve the issue, and that file doesn't get re-created if 16287933a8 "binman: Move to absolute imports" is applied.
Do you know what causes the issue, or how it can be avoided?
Maybe running "git clean -fdx" on the source tree before building would be a workaround, but I'd rather solve the root-cause if possible.
Actually I don't know. But the file you mention looks like something that Python 2 would create. So perhaps it is not allowed to run Python 2 on a project, then remove a file, then run Python 3. Since the file is removed (but not the .pyc), perhaps Python 3 gets confused? This seems like a bug though, since Python 3 really should not be looking at pyc files created by Python 2.
Regards, Simon
participants (2)
-
Simon Glass -
Stephen Warren