Build libpico in CI

[maxgerhardt]

For logs and artefacts see https://github.com/maxgerhardt/arduino-pico/actions/workflows/build-libpico.yml

Motivation: Build the libpico*.a files in CI, so that:

• builds are reproducable (we don't have to rely on users compiling those libraries, if they're using different compilers, may introduce subtle bugs)
• easy to adapt featureset of pico-sdk (e.g.; activate CYW43_PIO_CLOCK_DIV_DYNAMIC per Wifi on Pico W board doesn't work when the system frequency is too high, the program remains in an infinite loop #2590)
• users have a starting point to also build it / check it locally if they want to.
  • eliminates some pain points as e.g. encountered in Error building libpico #2549
• auto-triggers when Pico-SDK config is changed

Open points of discussion:

• What compiler versions to use exactly?
  • For ARM I used the one built into ubuntu-latest, which can compile the SDK files normally
  • if I want to use arm-none-eabi-gcc from https://github.com/earlephilhower/pico-quick-toolchain/releases/download/4.0.1/x86_64-linux-gnu.arm-none-eabi-8ec9d6f.240929.tar.gz, I run into Fix GCC14.1 compile error in w25x10cls.S raspberrypi/pico-sdk#2000, the SDK is not compilable
  • For RISC-V I used https://github.com/earlephilhower/pico-quick-toolchain/releases/download/4.0.1/x86_64-linux-gnu.riscv32-unknown-elf-8ec9d6f.240929.tar.gz
  • Optimally we want to use our custom toolchain for both builds?
• Renaming of output files?
  • the build generates e.g. build-rp2040/libpico-rp2040.a in the ZIP file
  • but this repo has it as lib/rp2040/libpico.a, no CPU prefix

Artefact output: libpico.zip

Just for reference, non working with ARM toolchain from pico-quick-toolchain

            # ARM toolchain
            wget -O "$GITHUB_WORKSPACE/arm.tar.gz" "https://github.com/earlephilhower/pico-quick-toolchain/releases/download/4.0.1/x86_64-linux-gnu.arm-none-eabi-8ec9d6f.240929.tar.gz"
            tar xf "$GITHUB_WORKSPACE/arm.tar.gz"
            echo "$GITHUB_WORKSPACE/arm-none-eabi/bin" >> "$GITHUB_PATH"

[earlephilhower]

I'm a little worried that the gcc-arm-none-eabi and this core's GCC (12 or 14) are compatible because of different Newlib/libc configuration options. I'm particularly thinking about the locking/multithread options. Things may build, but they may not work properly. Other bits of Newlib probably won't come into play (i.e. printf nano/FP and DP implementations, etc.) since they'd be linked only in the final stage using the core toolchain.

If we're manually installing the R5 from the toolchain repo, then why not pull in the 2.0.3 version (last GCC12.4 build) from https://github.com/earlephilhower/pico-quick-toolchain/releases/download/2.3.0/x86_64-linux-gnu.arm-none-eabi-dfd82b2.240919.tar.gz

[earlephilhower]

Oops, I think I confirmed this ain't gonna work since GCC12.4's SDK can't be used with this core. I've got a patch in newlib and in the core to align the locks for FILEs.

There's no way the generic version has allocated the proper space (8 bytes, not 4) or is using the proper lock calls (nor did the GCC12).

You could wget https://patch-diff.githubusercontent.com/raw/raspberrypi/pico-sdk/pull/2000.patch and apply it, and then just use get.py to install the normal toolchain and no hard-coding needed. Once we move to 2.0.1 SDK, this patch can be dropped...

[maxgerhardt]

Oh yeah, that's a good idea! With get.py, the toolchain should always be right. I can store the .patch file locally and git apply it before compilation.

[maxgerhardt]

Works great! Latest commit now builds with the toolchains from get.py and downloads and applies the 2000.patch file dynamically.

Sadly the commits must be squashed, the merges messed up the history.. Never mind, I rebased it.

[earlephilhower]

Thx!