Use PGO during musl builds

[zanieb]

It's not clear why we're not using this. Let's see what happens.

[zanieb]

Well, that's a first problem

2025-03-19T22:14:54.8625163Z cpython-3.13> usage: build.py [-h] [-d] [-f] [-v] target
2025-03-19T22:14:54.8626404Z cpython-3.13> build.py: error: argument target: invalid get_target value: 'x86_64-unknown-linux-musl'
2025-03-19T22:14:54.8729341Z cpython-3.13> make[2]: *** [jit_stencils.h] Error 2
2025-03-19T22:14:54.8730619Z cpython-3.13> Makefile:2965: recipe for target 'jit_stencils.h' failed

resolved in db52d2b

[zanieb]

2025-03-19T23:16:36.4962413Z cpython-3.13> musl-clang -L/tools/deps/lib -Wl,--exclude-libs,ALL -LModules/_hacl  -flto=thin -g -fprofile-instr-generate -Xlinker -export-dynamic -o python Programs/python.o -L. -lpython3.13 -ldl  -lpthread     -lbz2          -lffi -ldl  -lm  -lncursesw  -lpanelw -lncursesw   -ldb  -lmpdec  -lexpat  -lcrypto        -llzma       -lrt         -lsqlite3  -lssl -lcrypto            -ltcl8.6 -ltk8.6 -lX11 -lxcb -lXau   -luuid      -lm    -lm   -lexpat  -ledit -lncursesw        -lz                       -lm
2025-03-19T23:16:36.4971610Z cpython-3.13> musl-clang -L/tools/deps/lib -Wl,--exclude-libs,ALL -LModules/_hacl  -flto=thin -g -fprofile-instr-generate -Xlinker -export-dynamic -o Programs/_testembed Programs/_testembed.o -L. -lpython3.13 -ldl  -lpthread -lbz2          -lffi -ldl  -lm  -lncursesw  -lpanelw -lncursesw   -ldb  -lmpdec  -lexpat  -lcrypto        -llzma       -lrt         -lsqlite3  -lssl -lcrypto            -ltcl8.6 -ltk8.6 -lX11 -lxcb -lXau   -luuid      -lm    -lm   -lexpat  -ledit -lncursesw        -lz                       -lm
2025-03-19T23:16:36.5088042Z cpython-3.13> clang-14clang-14: warning: argument unused during compilation: '-nostdinc' [-Wunused-command-line-argument]
2025-03-19T23:16:36.5088753Z cpython-3.13> :
2025-03-19T23:16:36.5089031Z cpython-3.13> warning:
2025-03-19T23:16:36.5089458Z cpython-3.13> argument unused during compilation: '-nostdinc' [-Wunused-command-line-argument]
2025-03-19T23:16:36.5763818Z cpython-3.13> /tools/host/bin/ld: /tools/llvm/lib/clang/14.0.3/lib/linux/libclang_rt.profile-x86_64.a(InstrProfilingFile.c.o): in function `parseAndSetFilename':
2025-03-19T23:16:36.5764605Z cpython-3.13> InstrProfilingFile.c:(.text.parseAndSetFilename+0xf9): undefined reference to `__strdup'
2025-03-19T23:16:36.5777376Z cpython-3.13> clang-14
2025-03-19T23:16:36.5778447Z cpython-3.13> :
2025-03-19T23:16:36.5779459Z cpython-3.13> error:
2025-03-19T23:16:36.5780850Z cpython-3.13> linker command failed with exit code 1 (use -v to see invocation)
2025-03-19T23:16:36.5797322Z cpython-3.13> Makefile:977: recipe for target 'python' failed
2025-03-19T23:16:36.5798690Z cpython-3.13> make[2]: *** [python] Error 1
2025-03-19T23:16:36.5800281Z cpython-3.13> make[2]: *** Waiting for unfinished jobs....
2025-03-19T23:16:36.7876207Z cpython-3.13> /tools/host/bin/ld: /tools/llvm/lib/clang/14.0.3/lib/linux/libclang_rt.profile-x86_64.a(InstrProfilingFile.c.o): in function `
2025-03-19T23:16:36.7877248Z cpython-3.13> parseAndSetFilename':
2025-03-19T23:16:36.7877702Z cpython-3.13> InstrProfilingFile.c:(.text.parseAndSetFilename+0xf9): undefined reference to `__strd

[zanieb]

This looks like an actual blocker, InstrProfilingFile.c:(.text.parseAndSetFilename+0xf9): undefined reference to '__strdup' — I don't know if we should pursue this further here. We might want to revisit once we're on a newer LLVM toolchain?

[indygreg]

The way PGO works is an extra library providing PGO instrumentation is linked automagically.

It looks like that library is referencing a symbol that isn't being linked in. It is likely that LLVM is making assumptions about which symbols are present and/or which extra libraries need to be linked to resolve all symbols. Those assumptions are likely tailored for glibc and don't hold on musl.

It is also possible that glibc only symbols are leaking into the LLVM PGO instrumentation library (because LLVM was compiled against glibc). In that case, we can't do much.

It is possible a newer version of LLVM has worked around this issue somehow. I'd focus on upgrading the toolchain. Then we can hash out PGO.