Build error in u-boot-dm/master

[Simon Glass]

Hi Stephen,

On Mon, 27 Apr 2020 at 12:44, Stephen Warren <swarren at 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 at 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