Static libavif looses debug info

[cmb69]

For RelWithDebInfo, (almost?) all debug info is lost, since we ignore avif_obj.pdb and yuv_a.pdb; and we do not even built aom with RelWithDebInfo, but rather Release. The latter is not nice, but the former makes the linker scream LNK4099, what is really annoying.

I'm filing this here since this is related to our builds, but might actually need a patch in https://github.com/winlibs/libavif, or even upstream.

[cmb69]

While working on this, I've learned that libavif merges all involved static libs into avif.lib when doing LOCAL builds (as we do). That means that the aom.lib we're shipping is completely useless for PHP at least.

Then I've learned that the way we're building currently, libyuv is automatically build behind the scenes (using FetchContent()). That means that we likely have no influence on how it's build.

And I've also learned that similar to libjpeg-turbo there is not only a single (or let's say three) static libraries, but some libs are build behind the scenes. So unless we'd be doing something like winlibs/libjpeg@1177955, there is no way to have fully working PDBs for static libavif, but libavif is way more complex than libjpeg and might be moving faster at this point in time.

So going with embedded debug info (/Z7) would be the only sensible way to accomplish having full debug info. That increases the size of avif_a.lib considerably, though (from ~20MB to ~60MB). However, most of that debug info is unused (as is most of AOM, I think); still, php_gd.pdb would almost tripple its size (not a real issue, since we're shipping PDBs separately in debug packages). Anyhow, a full build with embedded debug info: https://github.com/winlibs/winlib-builder/actions/runs/12890448139 (aom_a.lib and yuv_a.lib are included in that build).

If we want to go with embedded debug info, we should probably drop shipping aom_a.lib, and to make it optional dependency for ext/gd. A bit of an issue if we want to update libavif for stable PHP versions (would either need to ship the real aom_a.lib, or a basically empty fake).

Another option would be to actually have the three libraries, by doing non-LOCAL builds; haven't tried that so far that's not supported; would require patches to libavif. That would require adding an optional CHECK_LIB() for libyuv; again something that might not be okay for stable PHP versions.

An alternative would be to build a shared libavif, but see winlibs/libavif#1.

[cmb69]

An alternative would be to build a shared libavif, […]

Pros:

• no need to ship a fat static lib with embedded debug info (10MB DLL + 20MB PDB instead of 60MB static lib)
• already supported by PHP (8.1+, I think)
• no more need to patch libavif; might not be necessary at all; I think that could be passed as option when configuring

Cons:

• those who just would drop the new package into an existing deps folder would not get the new build (PHP checks static first)
• BC break

Test build: https://github.com/winlibs/winlib-builder/actions/runs/12892972580

---

Generally, I think shared libs are the way to head to. Static libs caused serious pain in the past (prior to adding the undocumented /d2:-AllowCompatibleILVersions switch, which I still consider somewhat dangerous), and of course the have the obvious benefits (and drawbacks; one would likely be mitigated with php/php-src#16958). Especially wrt libavif, it might be a good idea to go a step further and provide libaom as separate DLL; this could also be used by libheif, and possibly others.