expat: Add XML_STATIC to dependency

[fasterthanlime]

The current use of add_project_arguments works when compiling expat
itself, but it doesn't work when expat is a meson subproject of another
meson project.

Adding it as a compile_args of declare_dependency makes that usecase
work.

See also:

• https://gitlab.freedesktop.org/gstreamer/meson-ports/libffi/-/merge_requests/14
• Set G_INTL_STATIC_COMPILATION when making a static library frida/proxy-libintl#2

[fasterthanlime]

(If/when this is merged, it'd be lovely if this could be released as 2.2.9-4 - not sure if I'm supposed to do the bump in my own PR / how automated the release flow is)

[tp-m]

(If/when this is merged, it'd be lovely if this could be released as 2.2.9-4 - not sure if I'm supposed to do the bump in my own PR / how automated the release flow is)

You add a new revision to releases.json with your MR, then a new version will be created on merge.

See https://github.com/mesonbuild/wrapdb/blob/master/README.md

[fasterthanlime]

You add a new revision to releases.json with your MR, then a new version will be created on merge.

Woops, apologies for missing what is very clearly stated in the README. I updated releases.json as stated (and tested the wrap locally).

[eli-schwartz]

Please squash both commits into one.

[fasterthanlime]

Please squash both commits into one.

Done!

[eli-schwartz]

The CI is now complaining that this would be a good time to finally make the expat wrap obey standards by including a [provide] section (matching dependency('expat') -> /usr/lib/pkgconfig/expat.pc).

[fasterthanlime]

The CI is now complaining that this would be a good time to finally make the expat wrap obey standards by including a [provide] section

Just added one (that's hopefully correct). Unfortunately GitHub doesn't trust me yet, so every time I force-push, it waits for approval before running CI:

[fasterthanlime]

tools/sanity_checks.py now complains that the provides list changed - well, it did!

======================================================================
FAIL: test_releases (__main__.TestReleases) (step='have_same_provides', name='expat')
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\faste\bearcove\wrapdb\tools\sanity_checks.py", line 148, in test_releases
    self.assertEqual(sorted(deps), sorted(info.get('dependency_names', [])))
AssertionError: Lists differ: ['expat'] != []

First list contains 1 additional elements.
First extra element 0:
'expat'

- ['expat']
+ []

----------------------------------------------------------------------
Ran 3 tests in 8.666s

FAILED (failures=1, errors=1, skipped=1)

[eli-schwartz]

Not that it changed -- that the .wrap file and the releases.json disagree about what is there. You need to add it to both.

[fasterthanlime]

Not that it changed -- that the .wrap file and the releases.json disagree about what is there. You need to add it to both.

Got it - fixed that, and rebase on main, tools/sanity-checks.py finally runs locally (on WSL2).

It fails on Windows/MSVC for me:

[4/4] Linking target subprojects/expat-2.2.9/expat.dll
FAILED: subprojects/expat-2.2.9/expat.dll subprojects/expat-2.2.9/expat.pdb
"clang"  -Wl,/MACHINE:X64 -Wl,/OUT:subprojects/expat-2.2.9/expat.dll subprojects/expat-2.2.9/expat.dll.p/lib_xmlparse.c.obj subprojects/expat-2.2.9/expat.dll.p/lib_xmlrole.c.obj subprojects/expat-2.2.9/expat.dll.p/lib_xmltok.c.obj "-Wl,/nologo" "-Wl,/release" "-Wl,/nologo" "-Wl,/DEBUG" "-Wl,/PDB:subprojects\expat-2.2.9\expat.pdb" "-Wl,/DLL" "..\subprojects\expat-2.2.9\lib/libexpat.def" "-Wl,/IMPLIB:subprojects\expat-2.2.9\expat.lib" "-lkernel32" "-luser32" "-lgdi32" "-lwinspool" "-lshell32" "-lole32" "-loleaut32" "-luuid" "-lcomdlg32" "-ladvapi32"
..\subprojects\expat-2.2.9\lib\libexpat.def : fatal error LNK1107: invalid or corrupt file: cannot read at 0x884
clang: error: linker command failed with exit code 1107 (use -v to see invocation)
ninja: build stopped: subcommand failed.

..but manually running meson setup + meson compile doesn't fail for me with --default-library static and --default-library shared, so 🤷 not sure what's up.

---

Here's what my manual dynamic build does:

[4/4] "link"  /MACHINE:x64 /OUT:subprojects/expat-2.2.9/expat.dll subprojects/expat-2.2.9/expat.dll.p/lib_xmlparse.c.obj subprojects/expat-2.2.9/expat.dll.p/lib_xmlrole.c.obj subprojects/expat-2.2.9/expat.dll.p/lib_xmltok.c.obj "/nologo" "/release" "/nologo" "/DEBUG" "/PDB:subprojects\expat-2.2.9\expat.pdb" "/DLL" "/DEF:..\subprojects\expat-2.2.9\lib/libexpat.def" "/IMPLIB:subprojects\expat-2.2.9\expat.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "comdlg32.lib" "advapi32.lib"

(Which seems correct, using /DEF: to pull in the .def file).

And here's what my manual static build does:

[4/4] "lib" "/NOLOGO" /MACHINE:x64 /OUT:subprojects/expat-2.2.9/libexpat.a subprojects/expat-2.2.9/libexpat.a.p/lib_xmlparse.c.obj subprojects/expat-2.2.9/libexpat.a.p/lib_xmlrole.c.obj subprojects/expat-2.2.9/libexpat.a.p/lib_xmltok.c.obj

(Which seems correct too, not pulling in the .def file at all - it's only for DLLs afaik).

[eli-schwartz]

Downloading expat source from https://github.com/libexpat/libexpat/releases/download/R_2_2_9/expat-2.2.9.tar.xz
HTTP Error 503: Egress is over the account limit.

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

[eli-schwartz]

Ok, retriggering it worked.

[eli-schwartz]

Thanks!

[fasterthanlime]

Thanks for helping drive this to the finish line! Really appreciate it 💖

[eli-schwartz]

The intermittent error happens because GitHub releases artifacts uses Azure instead of AWS to combat the AWS outage, but seemingly GitHub's service account is not in good standing with their own parent company.