windows/mingw strange compiler error when freezing viper code
I was tring to freeze some libraries into a mingw windows build today, forgetting there was viper code in some of them.
There's an odd compiler error though that took me way too long to figure out was related to the viper functions, so thought it was worth documenting here:
micropython/ports/windows$ make CROSS_COMPILE=i686-w64-mingw32- FROZEN_MANIFEST=manifest.py
...
CC build/frozen_content.c
/tmp/ccm1KbYo.s: Assembler messages:
/tmp/ccm1KbYo.s:225: Warning: Ignoring changed section attributes for .text
/tmp/ccm1KbYo.s:225: Error: junk at end of line, first unrecognized character is `,'
/tmp/ccm1KbYo.s:270: Warning: Ignoring changed section attributes for .text
/tmp/ccm1KbYo.s:270: Error: junk at end of line, first unrecognized character is `,'
building from current master (d42cba0d22c) with
$ i686-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-w64-mingw32/9.3-win32/lto-wrapper
Target: i686-w64-mingw32
Configured with: ../../src/configure --build=x86_64-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir='/usr/lib/x86_64-linux-gnu' --libexecdir='/usr/lib/x86_64-linux-gnu' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --enable-shared --enable-static --disable-multilib --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes --with-tune=generic --with-headers=/usr/i686-w64-mingw32/include --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-lto --enable-threads=win32 --program-suffix=-win32 --program-prefix=i686-w64-mingw32- --target=i686-w64-mingw32 --with-as=/usr/bin/i686-w64-mingw32-as --with-ld=/usr/bin/i686-w64-mingw32-ld --enable-libatomic --enable-libstdcxx-filesystem-ts=yes --enable-dependency-tracking
Thread model: win32
gcc version 9.3-win32 20200320 (GCC)
details:
micropython/ports/windows$ cat manifest.py
freeze("../../tests/micropython")
micropython/ports/windows$ make CROSS_COMPILE=i686-w64-mingw32- FROZEN_MANIFEST=manifest.py CFLAGS_EXTRA='-save-temps'
...
frozen_content.s:6875: Error: junk at end of line, first unrecognized character is `,'
make: *** [../../py/mkrules.mk:77: build/build/frozen_content.o] Error 1
src/micropython/ports/windows$ awk 'NR==6872,NR==6878{print NR" "$0}' frozen_content.s
6872 .word 4086
6873 .word -28951
6874 .word 1
6875 .section .text,"ax",@progbits # ,"dr"
6876 .align 32
6877 _fun_data_native_const_intbig__lt_module_gt__f:
6878 .ascii "USATAUH\203\354"
I gather for actual viper support on windows we'll need a finished version of https://github.com/micropython/micropython/pull/4699 but this error looks like it'll need a fix similar to https://github.com/micropython/micropython/pull/2851 based on the issues that PR closed?
mpy-cross creates corrupt .mpy's on windows
I try to use frozen bytecode in stmhal in a windows/mingw environment. After compiling a python script to micropython bytecode with mpy-cross.exe i get a .mpy file as expected. If i then apply the mpy-tool.py on the .mpy file it raises an IndexError:
Creating build-STM32L476DISC/frozen_mpy.c
python3.5 ../tools/mpy-tool.py -f -q build-STM32L476DISC/genhdr/qstrdefs.preprocessed.h build-STM32L476DISC/freeze/test_script.mpy > build-STM32L476DISC/frozen_mpy.c
Traceback (most recent call last):
...
File "../tools/mpy-tool.py", line 357, in read_uint
b = bytes_cons(f.read(1))[0]
IndexError: index out of range
Makefile:301: recipe for target 'build-STM32L476DISC/frozen_mpy.c' failed
mingw32-make: *** [build-STM32L476DISC/frozen_mpy.c] Error 1
mingw32-make: *** Deleting file 'build-STM32L476DISC/frozen_mpy.c'
When i compared the bytecode that is generated in linux environments to the bytecode in windows environment the bytecode differs when it comes to a newline character in the bytecode (0xa). It seems that when the bytecode is generated by mpy-cross it prints out a newline (0xa) character somewhere and this is resolved to a linefeed-only in linux and to a carriage return (0xd) + linefeed (0xa) in windows. If the additional carriage return is removed freezing works.
I think the additional carriage return is not comming from the input python scripts, because in my windows environment i already tried linux encoded line endings and mpy-cross nevertheless failed.
Simple python script that produces the error (with windows newlines, apart from others that i tried):
test_script_class.py.txt
Resulting .mpy on windows
test_script_class_win.mpy.txt
Resulting .mpy on linux
test_script_class_linux.mpy.txt
Until now i could not figure out where the problem comes from.
br,
Sebastian