After some debugging I was able to determine that the Win32 DLL was failing to load libgcc_s_sjlj-1.dll. If we statically link libgcc instead, there should be no runtime dependency on libgcc.
PiperOrigin-RevId: 448338965
When I tried the previous `arm64` wheel on macOS, I discovered that `pip` on macOS only supports the `arm64` platform tag in a limited set of circumstances. pip seems to prefer `universal2` wheels.
To build a `universal2` wheel, we must run the `llvm-lipo` tool to bundle multiple `cc_binary()` outputs into a single output wheel. We use a transition to depend on multiple architectures for the extension, if we see that we are building for a multiarch CPU.
PiperOrigin-RevId: 447486256
While I've made some progress debugging b/231485326, I'm not going to be able to get this fully working in time for -rc1.
If I can debug this before the final release, we can re-enable the win32 wheels.
PiperOrigin-RevId: 446849335
This should get us the full set of binary wheels we need for release. Also added acceptance tests for all wheels except aarch64 (on Linux and macos): we cannot test these without emulation, which will require a somewhat more complicated setup.
PiperOrigin-RevId: 446574958
1. For some reason the version script was not working, it was failing to export the main symbol for the Python extension. I fixed this by using the `visibility` attribute instead to export the `PyInit__message` function.
2. We were not properly stripping the `python/dist/` prefix for the C module, which was making the module exported under the name `dist.google._upb` instead of `google._upb`.
3. The `py_library()` rule was failing to actually propagate the module file into the wheel, so I just removed it.
PiperOrigin-RevId: 445446611
Mike Kruskal
Protobuf Team
Joshua Haberman