All of lore.kernel.org
 help / color / mirror / Atom feed
* Build error in u-boot-dm/master
@ 2020-04-27 16:04 Stephen Warren
  2020-04-27 17:02 ` Simon Glass
  0 siblings, 1 reply; 4+ messages in thread
From: Stephen Warren @ 2020-04-27 16:04 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Build error in u-boot-dm/master
  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
  0 siblings, 1 reply; 4+ messages in thread
From: Simon Glass @ 2020-04-27 17:02 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Build error in u-boot-dm/master
  2020-04-27 17:02 ` Simon Glass
@ 2020-04-27 18:44   ` Stephen Warren
  2020-04-27 22:25     ` Simon Glass
  0 siblings, 1 reply; 4+ messages in thread
From: Stephen Warren @ 2020-04-27 18:44 UTC (permalink / raw)
  To: u-boot

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Build error in u-boot-dm/master
  2020-04-27 18:44   ` Stephen Warren
@ 2020-04-27 22:25     ` Simon Glass
  0 siblings, 0 replies; 4+ messages in thread
From: Simon Glass @ 2020-04-27 22:25 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-04-27 22:25 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 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.