Update/build pipeline - #11
Merged
Merged
Conversation
…missing mbedtls submodule Real CI failures from the first run of the rewritten pipeline (runs 30268724674, 30268724579): - usermod.yml set BUILD as a job-level env:, which leaked into the separate "Build mpy-cross"/"Build libffi (deplibs)" steps in the same job. py/mkenv.mk's BUILD ?= build doesn't override an inherited env var, so mpy-cross ended up built under usermod/build/<arch> instead of its own default location, and the main build's hardcoded lookup at mpy-cross/build/mpy-cross then failed. Switched BUILD to a local shell var scoped to just the step that needs it. - natmod/Makefile linked xtensa/xtensawin against the toolchain's own newlib libm.a via LINK_RUNTIME, which pulls in lib_a-s_lib_ver.o (fdlibm's _LIB_VERSION global) to satisfy atan2f -- that object has a non-empty .data section, and mpy_ld.py hard-rejects any .data in a linked native module. Moved xtensa/xtensawin to the same fdlibm-from-source route already used for RISC-V, which has no such global. - usermod.yml's rp2040 job was missing lib/mbedtls from its submodule list; ports/rp2/CMakeLists.txt requires it unconditionally.
… -Werror
Continuing from the previous fix round -- these are the next layer of
real failures surfaced by CI runs 30271814464/30271814433:
- usermod.yml's aarch64/armhf/mipsel "Build libffi (deplibs)" steps never
passed BUILD=, so libffi.a got built under the port's default build dir
while the main build (which does pass a custom BUILD=) looked for it
under usermod/build/<arch>/lib/libffi/out/lib/ -- "ld: cannot find
.../libffi.a". Both steps must agree on the same BUILD.
- natmod/Makefile's xtensa/xtensawin fix from the last round (moving them
to the fdlibm-from-source route) dropped the implicit libgcc.a link
that LINK_RUNTIME used to provide, surfacing "undefined symbol:
__lesf2" (soft-float compare builtin). Extended the existing RISC-V
libgcc.a flag to also cover xtensa/xtensawin.
- usermod.yml's wasm job now fails on MicroPython v1.28.0's own
ports/webassembly/main.c ("external_call_depth" set but not used)
against a newer emsdk/clang's -Wunused-but-set-global, and that port's
Makefile hardcodes -Werror with no override hook. Passed
CFLAGS="-Wno-unused-but-set-global" on the build command line (a
genuine -Wno-X disables the diagnostic outright, so it isn't affected
by the Makefile's own later -Werror the way -Wno-error=X would be).
…ing includes - natmod.yml: xtensawin (the only esp-idf-toolchain leg) failed with "Please run 'pip install ar' to link .a files" even though that pip install already ran -- esp-idf's export.sh puts its own python venv ahead of PATH, so the earlier "Install Python tools" step installed pyelftools/ar into a *different* python3 than the one active once export.sh is sourced again for the actual build. Re-run pip install right after sourcing export.sh in the build step itself. xtensa (plain tarball toolchain, no export.sh) was never affected -- it already built clean in the last run. - usermod.yml wasm job: the CFLAGS="-Wno-unused-but-set-global" fix from the last round was wrong -- a make command-line assignment is an override variable that blocks *every* in-makefile assignment to that name (including += ones, per GNU Make's override semantics), so it replaced the port's whole CFLAGS instead of adding to it, deleting the include paths that normally arrive via CFLAGS += $(INC) (confirmed by a real CI failure: every py/*.h include vanished). CC has no += anywhere in py.mk or this port's Makefile, so CC="emcc -Wno-unused-but-set-global" is a safe drop-in instead.
…iant The CC="emcc -Wno-unused-but-set-global" workaround from the last commit didn't actually take effect (same -Werror failure in the next CI run, run 30273897133) -- moot anyway, since the real issue is bigger than one warning: the default `standard` webassembly variant (-s ASYNCIFY) is broken against modern emsdk, tracked upstream at micropython/micropython#19380 (filed against this exact v1.28.0 + emsdk latest combination). Upstream's maintainer recommendation there is to use the pyscript variant instead, which doesn't use ASYNCIFY at all -- same variant a7p's own webassembly job already uses, which is why a7p never hit this. Our own FROZEN_MANIFEST still overrides pyscript's default (large) manifest.py, so this doesn't pull in anything extra.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.