Closed joeyparrish closed 9 months ago
Looking at this again, it's possible that both targets (libpackager_shared and libpackager_static) are trying to create an import lib under the same name (libpackager.lib). Whether this works or not may merely depend on the timing of whether the old one (shared, according to log timestamps) is still open and in use when the new one (static) is being written.
I'll upload a draft PR that will build them both under different names (no aliases) on Windows and see if .lib
files are being generated for both targets. If so, that would point strongly at both a cause (the aliases) and a solution (only build one or the other).
My PR showed that .lib files were generated for both static and shared targets:
-rw-r--r-- 1 runneradmin 197121 251324 Feb 14 23:19 libpackager_shared.lib
-rw-r--r-- 1 runneradmin 197121 1058494 Feb 14 23:19 libpackager_static.lib
So having both alias to libpackager causes a collision that explains this issue.
So I think we should just build one target or the other.
The windows shared build is failing on occasion with:
It then passes when re-run. I think this indicates a race condition somewhere in the parallel build, but I'm not sure of the nature of it.
Here is a failed build: https://github.com/shaka-project/shaka-packager/actions/runs/7906044243/job/21580055244?pr=1340 Followed by a successful rerun: https://github.com/shaka-project/shaka-packager/actions/runs/7906044243/job/21585322587?pr=1340
Failed build
Here are log snippets from the failed build:
Building libpackager_shared
Building libpackager_static (fails)
Successful build (rerun)
Here are log snippets from the successful build (rerun):
Building libpackager_shared
Building libpackager_static (works)
Possible solutions
We could find the root of this MSVC failure (timing?) and resolve it. @cosmin also suggests that we shouldn't be building two library configurations at once, so maybe we could restructure the targets so that we only ever build libpackager_static or libpackager_shared, but not both.