MicroPython UNIX does not compile on FreeBSD #24

paulc · 2014-01-01T21:18:26Z

Hello,

Tried compiling MicroPython UNIX on FreeBSD 9.2 (amd64) and although the majority of the code complies fine I had the following problems:

a) Need to use 'gmake' rather than 'make' (this just needs a note in the docs)

b) malloc.h is deprecated and should be replaced with stdlib.h (think this is true on Linix as well)

gcc -I. -I../py -Wall -Werror -ansi -std=gnu99 -Os -DUSE_READLINE -c -o build/main.o main.c
In file included from main.c:4:
/usr/include/malloc.h:3:2: error: #error "<malloc.h> has been replaced by <stdlib.h>"
cc1: warnings being treated as errors
main.c: In function 'do_repl':
main.c:76: warning: implicit declaration of function 'free'
gmake: *** [build/main.o] Error 1

Replacing malloc.h with stdlib.h fixes the problem and allows most the the rest of the code to complie cleanly.

c) mp_map_t is redefined

gcc -I. -I../py -Wall -Werror -ansi -std=gnu99 -Os -DUSE_READLINE -c -o build/runtime.o ../py/runtime.c
In file included from ../py/runtime.c:17:
../py/map.h:18: error: redefinition of typedef 'mp_map_t'
../py/obj.h:117: error: previous declaration of 'mp_map_t' was here
gmake: *** [build/runtime.o] Error 1

Haven't been able to work out logic of includes to fix this yet

dpgeorge · 2014-01-01T21:32:38Z

I changed the declaration in obj.h to try and fix point (c). Let me know if it worked.

redteam316 · 2014-01-01T23:34:01Z

replacing malloc.h with stdlib.h is the correct fix, it is the proper way to include it. Issue #27 is basically a duplicate of this.

paulc · 2014-01-02T01:14:38Z

Damien,

Thanks for the quick turn around. The obj.h fix solved the declaration problem. I still needed to manually patch main.c to import stdlib.h rather than malloc.h but with this change the py and cpy interpreters built cleanly.

I ran the test suite - the basic tests all passed however a number of the bytecode tests failed (though I am not sure if this is expected (output below).

One minor point - the 'run-tests.sh' expects /bin/bash to be present (and doesn't work with /bin/sh) - for portability this should be "#!/usr/bin/env bash"

So - to build on FreeBSD now just requires:

The stdlib.h patch
The bash change
Note about needing bash & python3 packages

Paul.

--- Bytecode test output
Testing directory mp-tests...
assert1             :     17 lines, 100.0% correct
assign1             :     38 lines, 100.0% correct
assign2             :     33 lines, 100.0% correct
augassign1          :     37 lines, 100.0% correct
call1               :     13 lines, 100.0% correct
class1              :     30 lines, 100.0% correct
class2              :     36 lines, 100.0% correct
class3              :     85 lines, 100.0% correct
class4              :     69 lines, 100.0% correct
class5              :     94 lines, 100.0% correct
closure1            :      7 lines, 100.0% correct
closure2            :     40 lines, 100.0% correct
closure3            :     56 lines, 100.0% correct
closure4            :     61 lines, 100.0% correct
compare1            :     75 lines,  98.7% correct
const1              :     17 lines,  94.1% correct
continue1           :    151 lines,  94.7% correct
decorate1           :     87 lines, 100.0% correct
del1                :     54 lines, 100.0% correct
del2                :     28 lines, 100.0% correct
dict1               :     22 lines, 100.0% correct
dictcomp1           :     53 lines, 100.0% correct
docstring1          :     53 lines, 100.0% correct
docstring2          :      9 lines, 100.0% correct
fun1                :     22 lines, 100.0% correct
fun2                :    134 lines, 100.0% correct
fun3                :     43 lines, 100.0% correct
if1                 :     70 lines, 100.0% correct
if2                 :     60 lines, 100.0% correct
if3                 :     33 lines,  93.9% correct, 1 bad 3-field
if4                 :     40 lines,  97.5% correct
ifexpr1             :     13 lines, 100.0% correct
import1             :     32 lines, 100.0% correct
import2             :     13 lines, 100.0% correct
import3             :     47 lines, 100.0% correct
import4             :     22 lines, 100.0% correct
import5             :     33 lines, 100.0% correct
lambda1             :     31 lines, 100.0% correct
lambda2             :     18 lines, 100.0% correct
list1               :     41 lines, 100.0% correct
list2               :     39 lines, 100.0% correct
listcomp1           :     79 lines, 100.0% correct
listcomp2           :     29 lines, 100.0% correct
listcomp3           :     60 lines, 100.0% correct
listcomp4           :     44 lines, 100.0% correct
listcomp5           :    186 lines, 100.0% correct
locals1             :     91 lines, 100.0% correct
ptex                :   1085 lines,  97.9% correct, 1 bad 3-field
raise1              :     70 lines,  98.6% correct
scope0              :     30 lines, 100.0% correct
scope1              :     43 lines, 100.0% correct
scope2              :     52 lines, 100.0% correct
scope3              :     58 lines, 100.0% correct
scope4              :     45 lines, 100.0% correct
scope5              :     56 lines, 100.0% correct
scope6              :     48 lines, 100.0% correct
scope7              :     78 lines, 100.0% correct
set1                :     29 lines, 100.0% correct
setcomp1            :     53 lines, 100.0% correct
slice1              :     95 lines, 100.0% correct
slice2              :     19 lines, 100.0% correct
string1             :     23 lines, 100.0% correct
string2             :     51 lines, 100.0% correct
super1              :    141 lines, 100.0% correct
try1                :     85 lines,  98.8% correct
try2                :     28 lines,  96.4% correct
try3                :     66 lines,  98.5% correct
try4                :    118 lines,  99.2% correct
try5                :     52 lines,  98.1% correct
try6                :     50 lines,  98.0% correct
tuple1              :     73 lines, 100.0% correct
tuple2              :     73 lines, 100.0% correct
tuple3              :     35 lines, 100.0% correct
with1               :     61 lines,  98.4% correct
yield1              :     69 lines, 100.0% correct
yield2              :     37 lines, 100.0% correct
Testing directory pylib-tests...
_compat_pickle      :    252 lines,  99.6% correct
_threading_local    :    449 lines,  99.1% correct, 1 bad 3-field
_weakrefset         :   1119 lines,  99.3% correct
abc                 :    613 lines,  98.7% correct, 1 bad 3-field
aifc                :   3301 lines,  98.7% correct, 6 bad 3-field
antigravity         :     95 lines, 100.0% correct
base64              :   1407 lines,  99.4% correct
bdb                 :   2545 lines,  98.5% correct, 7 bad 3-field
binhex              :   2030 lines,  99.4% correct, 6 bad 3-field
bisect              :    270 lines,  98.1% correct
bz2                 :   1554 lines,  99.1% correct, 5 bad 3-field
cProfile            :    675 lines,  98.8% correct
chunk               :    501 lines,  98.4% correct
code                :    700 lines,  98.7% correct
compileall          :    874 lines,  96.0% correct, 7 bad 3-field
contextlib          :    744 lines,  97.6% correct, 11 bad 3-field
crypt               :    222 lines,  98.2% correct
dummy_threading     :    138 lines,  99.3% correct
fnmatch             :    361 lines,  97.0% correct, 1 bad 3-field
genericpath         :    319 lines,  98.4% correct
getopt              :    768 lines,  98.4% correct
hashlib             :    302 lines,  97.4% correct
Traceback (most recent call last):
  File "unpyc.py", line 112, in 
    show_file(fname)
  File "unpyc.py", line 14, in show_file
    show_code(c, to_show_code)
  File "unpyc.py", line 24, in show_code
    disassemble(code)
  File "unpyc.py", line 85, in disassemble
    print(repr(co.co_consts[oparg]))
UnicodeEncodeError: 'ascii' codec can't encode character '\xe7' in position 36: ordinal not in range(128)
Traceback (most recent call last):
  File "check.py", line 5, in 
    lines_me = [l.strip('\n') for l in sys.stdin.readlines()]
  File "/usr/local/lib/python3.3/encodings/ascii.py", line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1465: ordinal not in range(128)
keyword             :    232 lines,  97.4% correct, 1 bad 3-field
macurl2path         :    390 lines,  98.5% correct
mimetypes           :   1546 lines,  98.8% correct
modulefinder        :   3037 lines,  98.2% correct
nturl2path          :    267 lines,  97.8% correct
opcode              :    724 lines, 100.0% correct
pipes               :    907 lines,  99.3% correct
poplib              :   1028 lines,  99.7% correct, 1 bad 3-field
pty                 :    666 lines,  98.2% correct
reprlib             :    861 lines,  98.3% correct, 10 bad 3-field
rlcompleter         :    440 lines,  96.6% correct
runpy               :    962 lines,  99.0% correct
sched               :    536 lines,  99.6% correct
shelve              :    787 lines,  99.5% correct
socket              :   1319 lines,  98.3% correct, 1 bad 3-field
socketserver        :   1729 lines,  98.6% correct, 8 bad 3-field
sre_constants       :    559 lines, 100.0% correct
stat                :    367 lines,  99.5% correct
struct              :     32 lines, 100.0% correct
sunau               :   1724 lines,  99.2% correct, 3 bad 3-field
symbol              :    249 lines,  99.2% correct
tabnanny            :   1181 lines,  97.9% correct, 3 bad 3-field
tempfile            :   2268 lines,  98.5% correct
this                :     76 lines, 100.0% correct
timeit              :    914 lines,  97.9% correct, 10 bad 3-field
tty                 :    170 lines, 100.0% correct
types               :    327 lines,  99.7% correct
uu                  :    697 lines,  97.8% correct, 2 bad 3-field
wave                :   1762 lines,  99.4% correct, 1 bad 3-field
weakref             :   1553 lines,  97.8% correct
xdrlib              :   1068 lines,  96.2% correct, 39 bad 3-field

dpgeorge · 2014-01-02T16:20:39Z

I've push changes for everthing except the notes about needing packages for bash and python3. What exactly should I say for this?

Dr-Syn · 2014-01-02T17:52:49Z

Just list it as a build requirement; I'll update the page I've started on the wiki to keep track of those things to reflect that.

atmel-samd: Enable full urandom module from extmod. Closes #17.

Update from adafruit/main

Linked in fb_alloc_mark

Although the original motivation given for the workaround[1] is correct, nlr.o and nlrthumb.o are linked with a small enough distance that the problem does not occur, and the workaround isn't necessary. The distance between the b instruction and its target (nlr_push_tail) is just 64 bytes[2], well within the ±2046 byte range addressable by an unconditional branch instruction in Thumb mode. The workaround induces a relocation in the text section (textrel), which isn't supported everywhere, notably not on musl-libc, where it causes a crash on start-up. With the workaround removed, micropython works on an ARMv5T Linux built with musl-libc. [1]: commit dd376a2 Author: Damien George <damien.p.george@gmail.com> Date: Fri Sep 1 15:25:29 2017 +1000 py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2). "b" on Thumb might not be long enough for the jump to nlr_push_tail so it must be done indirectly. [2]: Excerpt from objdump -d micropython: 000095c4 <nlr_push_tail>: 95c4: b510 push {r4, lr} 95c6: 0004 movs r4, r0 95c8: f02d fd42 bl 37050 <mp_thread_get_state> 95cc: 6943 ldr r3, [r0, micropython#20] 95ce: 6023 str r3, [r4, #0] 95d0: 6144 str r4, [r0, micropython#20] 95d2: 2000 movs r0, #0 95d4: bd10 pop {r4, pc} 000095d6 <nlr_pop>: 95d6: b510 push {r4, lr} 95d8: f02d fd3a bl 37050 <mp_thread_get_state> 95dc: 6943 ldr r3, [r0, micropython#20] 95de: 681b ldr r3, [r3, #0] 95e0: 6143 str r3, [r0, micropython#20] 95e2: bd10 pop {r4, pc} 000095e4 <nlr_push>: 95e4: 60c4 str r4, [r0, micropython#12] 95e6: 6105 str r5, [r0, micropython#16] 95e8: 6146 str r6, [r0, micropython#20] 95ea: 6187 str r7, [r0, micropython#24] 95ec: 4641 mov r1, r8 95ee: 61c1 str r1, [r0, micropython#28] 95f0: 4649 mov r1, r9 95f2: 6201 str r1, [r0, micropython#32] 95f4: 4651 mov r1, sl 95f6: 6241 str r1, [r0, micropython#36] @ 0x24 95f8: 4659 mov r1, fp 95fa: 6281 str r1, [r0, micropython#40] @ 0x28 95fc: 4669 mov r1, sp 95fe: 62c1 str r1, [r0, micropython#44] @ 0x2c 9600: 4671 mov r1, lr 9602: 6081 str r1, [r0, micropython#8] 9604: e7de b.n 95c4 <nlr_push_tail> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>

Although the original motivation given for the workaround[1] is correct, nlr.o and nlrthumb.o are linked with a small enough distance that the problem does not occur, and the workaround isn't necessary. The distance between the b instruction and its target (nlr_push_tail) is just 64 bytes[2], well within the ±2046 byte range addressable by an unconditional branch instruction in Thumb mode. The workaround induces a relocation in the text section (textrel), which isn't supported everywhere, notably not on musl-libc, where it causes a crash on start-up. With the workaround removed, micropython works on an ARMv5T Linux system built with musl-libc. [1]: commit dd376a2 Author: Damien George <damien.p.george@gmail.com> Date: Fri Sep 1 15:25:29 2017 +1000 py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2). "b" on Thumb might not be long enough for the jump to nlr_push_tail so it must be done indirectly. [2]: Excerpt from objdump -d micropython: 000095c4 <nlr_push_tail>: 95c4: b510 push {r4, lr} 95c6: 0004 movs r4, r0 95c8: f02d fd42 bl 37050 <mp_thread_get_state> 95cc: 6943 ldr r3, [r0, micropython#20] 95ce: 6023 str r3, [r4, #0] 95d0: 6144 str r4, [r0, micropython#20] 95d2: 2000 movs r0, #0 95d4: bd10 pop {r4, pc} 000095d6 <nlr_pop>: 95d6: b510 push {r4, lr} 95d8: f02d fd3a bl 37050 <mp_thread_get_state> 95dc: 6943 ldr r3, [r0, micropython#20] 95de: 681b ldr r3, [r3, #0] 95e0: 6143 str r3, [r0, micropython#20] 95e2: bd10 pop {r4, pc} 000095e4 <nlr_push>: 95e4: 60c4 str r4, [r0, micropython#12] 95e6: 6105 str r5, [r0, micropython#16] 95e8: 6146 str r6, [r0, micropython#20] 95ea: 6187 str r7, [r0, micropython#24] 95ec: 4641 mov r1, r8 95ee: 61c1 str r1, [r0, micropython#28] 95f0: 4649 mov r1, r9 95f2: 6201 str r1, [r0, micropython#32] 95f4: 4651 mov r1, sl 95f6: 6241 str r1, [r0, micropython#36] @ 0x24 95f8: 4659 mov r1, fp 95fa: 6281 str r1, [r0, micropython#40] @ 0x28 95fc: 4669 mov r1, sp 95fe: 62c1 str r1, [r0, micropython#44] @ 0x2c 9600: 4671 mov r1, lr 9602: 6081 str r1, [r0, micropython#8] 9604: e7de b.n 95c4 <nlr_push_tail> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>

Although the original motivation given for the workaround[1] is correct, nlr.o and nlrthumb.o are linked with a small enough distance that the problem does not occur, and the workaround isn't necessary. The distance between the b instruction and its target (nlr_push_tail) is just 64 bytes[2], well within the ±2046 byte range addressable by an unconditional branch instruction in Thumb mode. The workaround induces a relocation in the text section (textrel), which isn't supported everywhere, notably not on musl-libc[3], where it causes a crash on start-up. With the workaround removed, micropython works on an ARMv5T Linux system built with musl-libc. [1]: commit dd376a2 Author: Damien George <damien.p.george@gmail.com> Date: Fri Sep 1 15:25:29 2017 +1000 py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2). "b" on Thumb might not be long enough for the jump to nlr_push_tail so it must be done indirectly. [2]: Excerpt from objdump -d micropython: 000095c4 <nlr_push_tail>: 95c4: b510 push {r4, lr} 95c6: 0004 movs r4, r0 95c8: f02d fd42 bl 37050 <mp_thread_get_state> 95cc: 6943 ldr r3, [r0, micropython#20] 95ce: 6023 str r3, [r4, #0] 95d0: 6144 str r4, [r0, micropython#20] 95d2: 2000 movs r0, #0 95d4: bd10 pop {r4, pc} 000095d6 <nlr_pop>: 95d6: b510 push {r4, lr} 95d8: f02d fd3a bl 37050 <mp_thread_get_state> 95dc: 6943 ldr r3, [r0, micropython#20] 95de: 681b ldr r3, [r3, #0] 95e0: 6143 str r3, [r0, micropython#20] 95e2: bd10 pop {r4, pc} 000095e4 <nlr_push>: 95e4: 60c4 str r4, [r0, micropython#12] 95e6: 6105 str r5, [r0, micropython#16] 95e8: 6146 str r6, [r0, micropython#20] 95ea: 6187 str r7, [r0, micropython#24] 95ec: 4641 mov r1, r8 95ee: 61c1 str r1, [r0, micropython#28] 95f0: 4649 mov r1, r9 95f2: 6201 str r1, [r0, micropython#32] 95f4: 4651 mov r1, sl 95f6: 6241 str r1, [r0, micropython#36] @ 0x24 95f8: 4659 mov r1, fp 95fa: 6281 str r1, [r0, micropython#40] @ 0x28 95fc: 4669 mov r1, sp 95fe: 62c1 str r1, [r0, micropython#44] @ 0x2c 9600: 4671 mov r1, lr 9602: 6081 str r1, [r0, micropython#8] 9604: e7de b.n 95c4 <nlr_push_tail> [3]: https://www.openwall.com/lists/musl/2020/09/25/4 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>

Although the original motivation given for the workaround[1] is correct, nlr.o and nlrthumb.o are linked with a small enough distance that the problem does not occur, and the workaround isn't necessary. The distance between the b instruction and its target (nlr_push_tail) is just 64 bytes[2], well within the ±2046 byte range addressable by an unconditional branch instruction in Thumb mode. The workaround induces a relocation in the text section (textrel), which isn't supported everywhere, notably not on musl-libc[3], where it causes a crash on start-up. With the workaround removed, micropython works on an ARMv5T Linux system built with musl-libc. This commit changes nlrthumb.c to use a direct jump by default, but leaves the long jump workaround as an option for those cases where it's actually needed. [1]: commit dd376a2 Author: Damien George <damien.p.george@gmail.com> Date: Fri Sep 1 15:25:29 2017 +1000 py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2). "b" on Thumb might not be long enough for the jump to nlr_push_tail so it must be done indirectly. [2]: Excerpt from objdump -d micropython: 000095c4 <nlr_push_tail>: 95c4: b510 push {r4, lr} 95c6: 0004 movs r4, r0 95c8: f02d fd42 bl 37050 <mp_thread_get_state> 95cc: 6943 ldr r3, [r0, micropython#20] 95ce: 6023 str r3, [r4, #0] 95d0: 6144 str r4, [r0, micropython#20] 95d2: 2000 movs r0, #0 95d4: bd10 pop {r4, pc} 000095d6 <nlr_pop>: 95d6: b510 push {r4, lr} 95d8: f02d fd3a bl 37050 <mp_thread_get_state> 95dc: 6943 ldr r3, [r0, micropython#20] 95de: 681b ldr r3, [r3, #0] 95e0: 6143 str r3, [r0, micropython#20] 95e2: bd10 pop {r4, pc} 000095e4 <nlr_push>: 95e4: 60c4 str r4, [r0, micropython#12] 95e6: 6105 str r5, [r0, micropython#16] 95e8: 6146 str r6, [r0, micropython#20] 95ea: 6187 str r7, [r0, micropython#24] 95ec: 4641 mov r1, r8 95ee: 61c1 str r1, [r0, micropython#28] 95f0: 4649 mov r1, r9 95f2: 6201 str r1, [r0, micropython#32] 95f4: 4651 mov r1, sl 95f6: 6241 str r1, [r0, micropython#36] @ 0x24 95f8: 4659 mov r1, fp 95fa: 6281 str r1, [r0, micropython#40] @ 0x28 95fc: 4669 mov r1, sp 95fe: 62c1 str r1, [r0, micropython#44] @ 0x2c 9600: 4671 mov r1, lr 9602: 6081 str r1, [r0, micropython#8] 9604: e7de b.n 95c4 <nlr_push_tail> [3]: https://www.openwall.com/lists/musl/2020/09/25/4 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>

Although the original motivation given for the workaround[1] is correct, nlr.o and nlrthumb.o are linked with a small enough distance that the problem does not occur, and the workaround isn't necessary. The distance between the b instruction and its target (nlr_push_tail) is just 64 bytes[2], well within the ±2046 byte range addressable by an unconditional branch instruction in Thumb mode. The workaround induces a relocation in the text section (textrel), which isn't supported everywhere, notably not on musl-libc[3], where it causes a crash on start-up. With the workaround removed, micropython works on an ARMv5T Linux system built with musl-libc. This commit changes nlrthumb.c to use a direct jump by default, but leaves the long jump workaround as an option for those cases where it's actually needed. [1]: commit dd376a2 Author: Damien George <damien.p.george@gmail.com> Date: Fri Sep 1 15:25:29 2017 +1000 py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2). "b" on Thumb might not be long enough for the jump to nlr_push_tail so it must be done indirectly. [2]: Excerpt from objdump -d micropython: 000095c4 <nlr_push_tail>: 95c4: b510 push {r4, lr} 95c6: 0004 movs r4, r0 95c8: f02d fd42 bl 37050 <mp_thread_get_state> 95cc: 6943 ldr r3, [r0, micropython#20] 95ce: 6023 str r3, [r4, #0] 95d0: 6144 str r4, [r0, micropython#20] 95d2: 2000 movs r0, #0 95d4: bd10 pop {r4, pc} 000095d6 <nlr_pop>: 95d6: b510 push {r4, lr} 95d8: f02d fd3a bl 37050 <mp_thread_get_state> 95dc: 6943 ldr r3, [r0, micropython#20] 95de: 681b ldr r3, [r3, #0] 95e0: 6143 str r3, [r0, micropython#20] 95e2: bd10 pop {r4, pc} 000095e4 <nlr_push>: 95e4: 60c4 str r4, [r0, micropython#12] 95e6: 6105 str r5, [r0, micropython#16] 95e8: 6146 str r6, [r0, micropython#20] 95ea: 6187 str r7, [r0, micropython#24] 95ec: 4641 mov r1, r8 95ee: 61c1 str r1, [r0, micropython#28] 95f0: 4649 mov r1, r9 95f2: 6201 str r1, [r0, micropython#32] 95f4: 4651 mov r1, sl 95f6: 6241 str r1, [r0, micropython#36] @ 0x24 95f8: 4659 mov r1, fp 95fa: 6281 str r1, [r0, micropython#40] @ 0x28 95fc: 4669 mov r1, sp 95fe: 62c1 str r1, [r0, micropython#44] @ 0x2c 9600: 4671 mov r1, lr 9602: 6081 str r1, [r0, micropython#8] 9604: e7de b.n 95c4 <nlr_push_tail> [3]: https://www.openwall.com/lists/musl/2020/09/25/4 Signed-off-by: J. Neuschäfer <j.ne@posteo.net>

dpgeorge added a commit that referenced this issue Jan 1, 2014

py: change declaration of mp_map_t in obj.h (for issue #24).

df884fe

dpgeorge closed this as completed Jan 2, 2014

tannewt added a commit to tannewt/circuitpython that referenced this issue Oct 21, 2016

Merge pull request micropython#24 from adafruit/urandom

2cc1b25

atmel-samd: Enable full urandom module from extmod. Closes #17.

iabdalkader mentioned this issue Jan 23, 2020

pendsv_nlr_jump hard faults #315

Closed

tannewt pushed a commit to tannewt/circuitpython that referenced this issue Sep 11, 2020

Merge pull request micropython#24 from adafruit/main

7c162cd

Update from adafruit/main

WeActStudio pushed a commit to WeActStudio/micropython that referenced this issue Feb 14, 2021

Merge pull request micropython#24 from kwagyeman/fb_alloc_fix

c28705a

Linked in fb_alloc_mark

neuschaefer mentioned this issue Apr 27, 2023

py/nlrthumb: Make non-Thumb2 workaround opt-in. #11353

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MicroPython UNIX does not compile on FreeBSD #24

MicroPython UNIX does not compile on FreeBSD #24

paulc commented Jan 1, 2014

dpgeorge commented Jan 1, 2014

redteam316 commented Jan 1, 2014

paulc commented Jan 2, 2014

dpgeorge commented Jan 2, 2014

Dr-Syn commented Jan 2, 2014

MicroPython UNIX does not compile on FreeBSD #24

MicroPython UNIX does not compile on FreeBSD #24

Comments

paulc commented Jan 1, 2014

dpgeorge commented Jan 1, 2014

redteam316 commented Jan 1, 2014

paulc commented Jan 2, 2014

dpgeorge commented Jan 2, 2014

Dr-Syn commented Jan 2, 2014