From: Simon Glass <sjg@chromium.org>
To: u-boot@lists.denx.de
Subject: Build error in u-boot-dm/master
Date: Mon, 27 Apr 2020 16:25:08 -0600 [thread overview]
Message-ID: <CAPnjgZ00-baNxr6FJdvRm1Cu6FyMm0_+zpJ+E94n3kiEzpO-Ew@mail.gmail.com> (raw)
In-Reply-To: <a0bfd18f-a026-a41d-42f4-8401b34e58b7@wwwdotorg.org>
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
prev parent reply other threads:[~2020-04-27 22:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-27 16:04 Build error in u-boot-dm/master Stephen Warren
2020-04-27 17:02 ` Simon Glass
2020-04-27 18:44 ` Stephen Warren
2020-04-27 22:25 ` Simon Glass [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPnjgZ00-baNxr6FJdvRm1Cu6FyMm0_+zpJ+E94n3kiEzpO-Ew@mail.gmail.com \
--to=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.